Wobei ich ein konsequentes Verwenden von Fremdschlüsseln und die Transaktionsfähigkeit als primär wichtig ansehen würde! Generell empfinde ich das Festhalten an einer konkreten DB als Designfehler! Wozu gibt es denn odbc? Na klar verzichte ich dann auf spezielle Features des konkret eingesetzten DBMS, aber ich unterstütze eben "alles"! Damit steigen doch die Chacen eines Einsatzes enorm, da man nicht zum Einsatz eines neuen DBMS gewzungen wird, sondern ggf. ein bereits laufendes auch für diesen Taks verwenden kann. (Oder eben eines, mit dessen Wartung man sich gut auskennt!)
*gg* Ich erlaub mir mal ein kleines lächeln, da Du wohl noch nie eine größere Anwendung auf zwei Datenbanken lauffähig gehalten hast. Generell empfinde ich das Festhalten an einer konkreten DB als Designfehler!
Genau diese Einstellung führt dann erst zu den richtig groben Schnitzern. Dann wird nämlich begonnen Datenbankverhalten in der Anwendung nachzustricken. Ebay mag das mit viel Erfahrung und Manpower hinbekommen haben, aber Ottonormalprogrammierer scheitert damit immer kläglich sobald es sich um Multiuserumgebungen handelt.
Der einzige Weg eine Anwendung wirklich performant auf mehreren Plattformen laufen zu lassen, ist die Verwendung von Stored Procedures/Functions in denen die DB abhängigen Teile gekapselt werden. Wir haben zusätzlich noch einen Konverter geschrieben, der Oracle SQL nach Sybase SQLs konvertierte (gab da ein paar kleine aber feine Unterschiede).
Na klar verzichte ich dann auf spezielle Features des konkret eingesetzten DBMS
Ja eine einfache Adressverwaltung o.ä. könnte damit sogar laufen. Aber spätestens beim Locking musst Du die Unterschiede berücksichtigen. Aber wenn man mit dem Funktionsumfang einer sqlite zurecht kommt, dann kann man auch mit ODBC zugreifen.
odbc ist doch nur die verbindung zur db und wirklich etwas feines. In Einzelfällen und wenn es auf Performance ankommt kann man auch spezielle Bibliotheken einsetzen. Kauft sich dann aber wieder Probleme mit Versionsabhängigkeiten ein.
Aber mit den Rest stimm ich dir voll zu. View, gespeicherte Prozeduren, ... da gibt es eine Menge Funktionalität die man in die Datenbank rein packen kann und so sehr schnell schwierig wird auf ein anderes Datenbanksystem zu übertragen.
Selbst wenn man auf die ganzen feinen Spielsachen verzichtet kann man durch unterschiedliche Datentypen. Unterschiedlichen SQL-Dialekten und mangelhafter Unterstützung der Standards wie SQL99 ganz schnell schiffbruch erleiden. Selbst wenn es gleiche Ausdürcke in 2 verschiedenen Datenbanksystemen gibt, muss es noch lange nicht das selbe bewirken.
Generell empfinde ich das Festhalten an einer konkreten DB als Designfehler! Wozu gibt es denn odbc? Na klar verzichte ich dann auf spezielle Features des konkret eingesetzten DBMS, aber ich unterstütze eben "alles"! Damit steigen doch die Chacen eines Einsatzes enorm, da man nicht zum Einsatz eines neuen DBMS gewzungen wird, sondern ggf. ein bereits laufendes auch für diesen Taks verwenden kann. (Oder eben eines, mit dessen Wartung man sich gut auskennt!)
Generell empfinde ich das Festhalten an einer konkreten DB als Designfehler!
Genau diese Einstellung führt dann erst zu den richtig groben Schnitzern. Dann wird nämlich begonnen Datenbankverhalten in der Anwendung nachzustricken. Ebay mag das mit viel Erfahrung und Manpower hinbekommen haben, aber Ottonormalprogrammierer scheitert damit immer kläglich sobald es sich um Multiuserumgebungen handelt.
Der einzige Weg eine Anwendung wirklich performant auf mehreren Plattformen laufen zu lassen, ist die Verwendung von Stored Procedures/Functions in denen die DB abhängigen Teile gekapselt werden. Wir haben zusätzlich noch einen Konverter geschrieben, der Oracle SQL nach Sybase SQLs konvertierte (gab da ein paar kleine aber feine Unterschiede).
Na klar verzichte ich dann auf spezielle Features des konkret eingesetzten DBMS
Ja eine einfache Adressverwaltung o.ä. könnte damit sogar laufen. Aber spätestens beim Locking musst Du die Unterschiede berücksichtigen. Aber wenn man mit dem Funktionsumfang einer sqlite zurecht kommt, dann kann man auch mit ODBC zugreifen.
Dim
Aber mit den Rest stimm ich dir voll zu. View, gespeicherte Prozeduren, ... da gibt es eine Menge Funktionalität die man in die Datenbank rein packen kann und so sehr schnell schwierig wird auf ein anderes Datenbanksystem zu übertragen.
Selbst wenn man auf die ganzen feinen Spielsachen verzichtet kann man durch unterschiedliche Datentypen. Unterschiedlichen SQL-Dialekten und mangelhafter Unterstützung der Standards wie SQL99 ganz schnell schiffbruch erleiden. Selbst wenn es gleiche Ausdürcke in 2 verschiedenen Datenbanksystemen gibt, muss es noch lange nicht das selbe bewirken.
Für Windows und Microsoft Access User vielleicht [/ironie]