Mal ganz allgemein: Datenbankunabhängigkeit

[Tobias]

Hallo,
ich möchte mal ganz allgemein mit euch über Datenbankunabhängigkeit diskutieren - über Ansätze und Möglichkeiten da hinzukommen.

Die Datenbankunabhängigkeit ist für mich ein wesentlicher Aspekt der Plattformunabhängigkeit. Sicher ist es toll, wenn ich nicht an ein Betriebssystem gebunden bin, aber wenn mein Anwendung nur auf MSSQL läuft, bin ich ja doch wieder (indirekt) an Windows gefesselt. Java stellt mit JDBC schon eine tolle Möglichkeit her auf verschiedene Datenbanken zuzugreifen - nur ist das noch nicht alles. Eine Datenbank will auch abgefragt werden - und da fängt der Spaß trotz JDBC erst richtig an. Nicht jedes SQL-Statement wird auch von jeder Datenbank verstanden.
Also, was tun? Für jede Datenbank eigene SQL-Statements bereitstellen?

mpG
Tobias

 

[AlArenal]

Für sowas gibts Sachen wie Castor JDO ( http://castor.exolab.org/jdo.html ) und Hibernate ( http://www.hibernate.org/ ), wobei ich zuletzt noch Artikel und Kommentare las, in denen Hibernate besser wegkam.

 

[me.toString]

Ich glaube, dass du dir das ein wenig zu einfach vorstellst !
Die Plattformunabhängigkeit bei Java kommt daher zustande, dass SUN genau den Rahmen vorgibt (bzw. die VM selber schreibt ) ... daher hast du auf allen Plattformen das selber System.
Bei den DB's ist das ein wenig anders ... da will ja jeder abkassieren ... also macht man erstmal seinen eigenen Standard. Den Herstellern von DB's liegt doch nix daran, dass man ihre DB einfach mal so gegen eine andere austauschen kann.
Natürlich kann man mit den tollen Frameworks da eine gewisse datenbankunabhängigkeit erwirken ... aber so richtig ... nee. Die Frameworks arbeiten ja auch nur mit best. DB's zusammen ( die wichtigsten sind aber immer dabei ) ... wenn eine neue DB auf den Markt kommen würde, würden die Frameworks auch erstmal die Segel streichen müssen.
Ich will jetzt aber nicht gegen die Frameworks daher ziehen ... ich find die super, denn sie nehmen einem sehr viel Arbeit ab .... aber so richtig datenbankunabhängig bist du halt nicht.
Solange du nur mit einfachen SQL-Statements arbeitest, sollte es auch keine Probleme geben ... nur wenn du halt spezille Sachen machen willst ( Subselect, Trigger, Funktionen .... ), wird auch eine Framework Probleme bekommen, da die Techniken sich doch sehr unterscheiden bzw. gar nicht vorhanden sind.
z.B. Trigger bei Oracle und HSQLDB:
Bei Oracle wird der Trigger direkt in der DB gespeichert und die DB führt die Anweisungen gleich intern aus. Dagegen HSQLDB ... da musst du eine eigene Java-Klasse schreiben, die die Anweisungen enthält ... der Trigger wird dann nur noch mit der Tabelle und der Aktion verknüpft.
Im Endeffekt kommt bei beiden das selbe raus ... aber es wird auf verschiedensten Wegen realisiert ... wie willst du das alles unter einen Hut bekommen ???

 

[AlArenal]

Eine komplette DB-Unabhängigkeit gibt es nie, da gebe ich dir Recht. Aber das ist doch mit allem so, ich habe im Grunde nie mit irgendetwas 100%ige Unabhängigkeit und in der Praxis ist das auch gar nicht nötig.

Zu welchem Zweck sollte ich mir in der Praxis die Arbeit machen ein Produkt zu schaffen, dass 100%ig DB-unabhängig ist? Für ein DB-basiertes Produkt habe ich immer eine gewisse Zielgruppe und diese Zielgruppe fährt in der Regel zu 95% auf DBMS von vielleicht 2-5 Anbietern. Ob es für die übrigen 5% unter kostentechnischen Gesichtspunkten Sinn machen würde Anpassungen für Exoten zu fahren, wage ich zu bezweifeln. Oft ist es günstiger einfach die passende DBMS mitzuliefern und wenn das Produkt gut genug ist, wird der Kunde den Wechsel oder die zusätzliche Installation von sich aus in Erwägung ziehen.

Man muss ja auch sehen, das eine völlige DB-Unabhängigkeit auch dazu führt, dass ich die speziellen Fähigkeiten einzelner Systeme nur eingeschränkt oder gar nicht nutzen kann, womit ich mir einige Annehmlichkeiten von vornherein wegnehme.

Die Praxis ist ein Ort der Kompromisse, das gilt auch für die größten Idealisten.

 

[Tobias]

Geanu deshalb will ich das hier ja diskutieren! Ich weiß, wie schwierig es zu erreichen (bzw das es 100%-ig nicht zu erreichen) ist und möchte mit euch Ansätze diskutieren.
Ich präzisiere mein Problem: Ich schreibe ein Programm, das sich in bestehende IT-Architekturen einfügen muss (wie quasi jedes Programm). Die Kunden, für die dieses Programm gedacht ist, verfügen in der Regel über ein Datenbanksystem - und zwar eins der größeren: Oracle, MSSQL, usw. Es wird in naher Zukunft meiner Planung nach aber ein Kundenstamm dazukommen, der keine derartigen Systeme fährt und wirtschaftlich auf keinen Fall in der Lage ist ein paar tausend Euro für die Datenbank zu löhnen (letztlich soll für mich ja auch noch was übrigbleiben). Für diese Kunden möchte ich dann OpenSource- bzw kleinere, billigere DBs unterstützen.
Ich brauche also ein System, das es mir ermöglicht, durch Austausch einiger (Adapter-)Klassen auf ein anderes System zu switchen. Ein bestehendes Framework möchte ich nicht nutzen, da die viel zu viel können und meinen Code unnötig dick machen.

Ein Mindestanforderungskatalog für die DB ist in Arbeit. Ich dachte, das man als unterste Stufe in etwa MySQL oder PostgreSQL (wohl eher letzteres, auch wenn ich mich da noch nicht so gut auskenne) nimmt - also was die Unterstützung von Views und dergleichen angeht...

mpG
Tobias

 

[AlArenal]

Wenn du in deiner Anwendung in der untersten Schicht die DB-Zugriffe schön von allem anderen gekapselt hast, dann spricht im Grunde wenig dagegen diese Klassen entsprechend anzupassen und dann eben im Bedarfsfall auszutauschen. Da braucht es auch kein Wundersystem, denn i.d.R. weißt du ja welches DBMS beim Kunden zum Einsatz kommt oder lieferst es gleich mit.

Wenn du Views brauchst, nimm PostgreSQL. MySQL wird irgendwann demnächst mal welche unterstützrn, aber in PG sind sie schon seit Urzeiten drin und entsprechend findet sich mehr Literatur, das Ganze ist allerorten im Einsatz getestet, etc. Trigger, Stored Procedures, Foreign Keys, Subselects, etc haste da auch und die fehlen derzeit in MySQL noch samt und sonders (Subselects gibts derzeit nur in der 4.1, also nicht im Production Tree). Außerdem sparst du auch noch die Lizenzgebühren für MySQL, denn entgegen dem allgemeinen Irrglauben fallen im kommerziellen Einsatz Lizenzgebühren für MySQL an, wobei das Schriftwerk diesbezüglich bei MySQL etwas undurchsichtig ist, wewegen viele die Lizenz einfach kaufen, um auf Nummer sicher zu gehen.

 

[Tobias]

Also wenn ich die Lizenzbedingungen von MySQL richtig verstanden habe, fallen die Lizenzbedingungen nur an, wenn man MySQL als integralen Bestandteil der eigenen Applikation ausliefert oder Support nötig ist. Letzteres ist sicher kundenabhängig, aber ich würde MySQL als seperates Produkt verkaufen (bzw weitergeben) und nicht als Teil des Programms. Nichtsdestotrotz werde ich wohl eher PostGre nutzen, da es rein von der Funktionalität her eher an die großen Dinger ranreicht als MySQL.

mpG
Tobias

 

[Nacor]

Hi Tobias,

Dein Problem kenne ich , die gleichen Fragen habe ich mir auch schon gestellt. Lassen wir mal den ganzen theoretischen Scheiss weg. Es wird ein Weg gesucht, mehrere "grosse" DBs und mindestens eine halbwegs freie DB zu verwenden.
Nehmen wir mal Oracle, Sybase, MySQL und MSSQL Server (über ODBC Bridge).
Man sollte Build-In Funktionen (to_date, to_char, min, max, substring, char_length) mit Vorsicht geniessen.
Manche sind überall gleich, andere sind unterschiedlich.
Unterscheidlich ist das Datumskonzept. Die Länge einer Zeichenkette ist immer unterscheidlich.
Die aktuelle Zeit holen: sysdate (Oracle), getdate() (MSSQL, Sybase), now() (MySQL), also am besten zentral merere Varianten schreiben.
Wenn ein SQL-Statement zusammengesetzt wird, möglichst mit Prepare und ? arbeiten, Datumswerte mit PreparedStament.setTimestamp(..) setzen und nicht im String reinpfuschen.
Views fallen wegen MySQL aus, obwohl es eine gute Möglichkeit gewesen wäre den aktuellen Zeitpunkt zu holen.
Das Transaktionshandling sollte man auch zentral halten.

So, schon spät, viel Spaß