nicht angemeldet
Hi!
dann noch etwas richtung abtraktionslayer. er meinte, man könne auf treiberebene programmieren, sprich von programmiersprache auf eine datenbank zugreifen.
das problem ist, wenn man die datenbank wechselt, müsse man den ganzen code anpassen, dafür gäbe es dann abtraktionslayers.
und JDBC wäre zum beispiel ein abtraktionslayers. d.h., sollte man die datenbank ändern, müsse man nur eine funktion/wert/was auch immer in den jdbc einstellungen ändern, ohne den ganzen source code zu ändern.
Ja, diese Meinung existiert, das halte ich jedoch zum Großteil für einen Aberglauben. Das kann funktionieren, wenn man sich auf eine einfache SQL-Syntax beschränkt. Bei allem Weitergehenden kommt man schnell an die Grenzen, ab der man SQL-Dialekt-spezifische Dinge verwenden muss. Ein reiner Datenbankabstraktionslayer bringt schon eine Menge, aber muss an der Stelle passen, wenn es austauschbar sei soll.
Man kann weiter oben ansetzen und mit Objekt-Relation-Mappern hantieren. Dann hat man sich nur noch mit Objekten zu tun und der ORM kann sich um individuelle Syntaxprobleme beim Speichern und Lesen kümmern. Allerdings schränkt das auch die Flexibilität ein, wenn man spezielle Abfragen benötigt. Statt der umfänglichen Möglichkeiten von SQL im Allgemeinen und der Dialekte im Speziellen, hat man nur noch das was der ORM zur Verfügung stellt. Das mag eine Menge sein, aber nicht immer ausreichend. Dann ist man schnell bei Lösungen wie LINQ angekommen. Das simuliert quasi eine SQL-ähnliche Syntax, die aber auf der Ebene der Progammiersprache(n) beziehungsweise auf Framework-Ebene standardisiert ist. So kommt man gar nicht mehr in die Versuchung und die Gelegenheit, SQL-Dialekte selbst verwenden zu müssen. Hier ist man wieder flexibler als zuvor, aber kann immer noch nicht alle Feinheiten des DBMS ausnutzen. Und gerade die sind es, die man bei Entscheidungen für oder gegen ein bestimmtes System aus technischer Sicht berücksichtigen sollte. Wenn sich alle DBMSe gleich bedienen lassen, braucht man eigentlich nur noch den Preis zur Entscheidung heranzuziehen (etwas übertrieben. Systemwartung abseits der Anwendungen kommt ja auch noch hinzu). Abstraktionslayer sind in gewisser Weise nicht nur programmierfreundlicher sondern auch managementfreundlicher.
Und was auch noch bleibt, ist das Kapseln von speziellen Aufgaben in Stored Procedures. Die sollte ein guter ORM neben dem Objekt-Zugriff auch noch bieten. Hier kann man dann doch wieder alles ausnutzen, was das DBMS bietet. Muss dann aber auch bei einem Wechsel dies Routinen in den neuen Dialekt umschreiben.
wenn ich nun mit java programmiere und eine db verbindung aufbaue (da ist der mysql treiber eingebunden und JDBC auch) und im source codes viele selects und inserts habe und später die datenbank wechsle, dann ändere ich ja den JDBC oder irgendwelchen parameter bei jdbc, aber das problem ist ja, dass ich viele selects und inserts in meinen codes habe und die sind ja für alle datenbanken ja nicht gleich die notation, da muss ich ja dann trotzdem anpassungen im source code vornehmen
Bei einfachen Statements ist das noch problemlos. Die unterschiedliche Syntax, was die Stringbegrenzer anbelangt, bekommt man durch Funktionen im Layer oder durch konsequenten Einsatz von Prepared Statements gelöst.
Lo!