Datenbank Abstraktionsschicht

[Nightfly]

Hi

Ich soll jetzt mal wieder was in Delphi schreiben, diesmal mit ner neuen Datenbank, dem AdvantageDatabaseServer... toll, der hat sogar Komponenten.

Gibts nich auch Komponenten, bei denen ich ans andere Ende alle SQL Datenbanken hängen kann? So ne schöne zwischenschicht quasi, um unabhängig zu sein?

[Phoenix]

Also die BDE wäre sowas, aber die sollte man ja nicht mehr verwenden.

Wenn Du im .NET - Bereich arbeitest bietet Dir ADO.NET zumindest größtenteils diese Zwischenschicht, da Du da auf den Interfaces der ADO-Komponenten arbeiten kannst. Problematisch wird das nur, wenn Deine Datenbanken unterschiedliche SQL-Syntax haben (z.B. inner/outer Joins bei Oracle und SQL Server).

Ich bin derzeit dran da ein entsprechendes Framework zu bauen das auch SQL-Dialekt-unabhängig ist, aber das ist derzeit noch weit davon entfernt produktiv einsetzbar zu sein. Und wenn wird das auch nicht gerade billig sein ;-)

Ansonsten schau Dir mal ECO II an. Das soll sowas auch recht gut können.

[xaromz]

Hallo,

DBExpress lässt sich wunderbar per DLL für beliebige Datenbanken erweitern. Ich hab mir selbst darauf aufbauend eine Komponente gebaut, die auf verschiedene Datenbanken zugreifen kann (momentan mySQL, DB2, Oracle und MSSQL). Da ich leider momentan keinen Zugang zu den verschiedenen Datenbanken habe, konnte ich nur mySQl und DB2 testen.

Gruß
xaromz

[mkinzler]

Es gäbe auch noch die Möglichkeit ODBC zu verwenden. Oder für vorhandene Abstraktionsframeworks ( z.B. ZeosDBO) weiter Zugriffsschicht für ADS implementieren.

[Lemmy]

Hi,

wenn Ihr wirklich ne Abstraktionsschicht braucht, dann schreib Dir eine! Damit hast Du zum einen wirklich eine Datenbankunabhängigkeit, da für jede neue DB eine weitere Klasse fällig wird, zum anderen kannst Du aber in der jeweiligen Klasse die jeweiligen Eigenschaften der Datenbank voll ausnutzen.

Du musst einzig und allein sehr fit in OOP sein....

Grüße
Lemmy

[Nightfly]

Die Idee kam mir auch schon, klingt verlockend, aber mit der Zeit die ich hab schauts da sehr böse aus ;)

Was spräche gegen ODBC?

[Bernhard Geyer]

Zitat:

Zitat von Nightfly

Die Idee kam mir auch schon, klingt verlockend, aber mit der Zeit die ich hab schauts da sehr böse aus ;)

Wenn du mehrere DB's unterstützen willst kommst Du nicht drum rum gleich am Anfang genügend Zeit zu investieren sonst mußt du später noch mehr Zeit investieren.

Zitat:

Zitat von Nightfly

Was spräche gegen ODBC?

- Du mußt Treiber installieren (Admin-Rechte, DLL-Hölle)
- Nicht alle Features aller DB's sind über ODBC verfügbar
- ODBC ist eh Auslaufmodell (gibts nicht mehr unter Win64)

[Nightfly]

Ich bin ja hier nur der doofe Praktikant... das ich mehrere DB's unterstützen will ist meine eigene Motivation, mein Chef ließe mich am liebsten noch mit Paradox entwickel, zukunftsträchtigkeit interessiert hier keinen, (ich entwickle mit Delphi 5!!).

Hmmm...ok, ODBC fällt damit wohl erstmal Flach...damn...weitere Vorschläge außer selbst Implementieren?

[Flocke]

Zitat:

Zitat von Bernhard Geyer

- ODBC ist eh Auslaufmodell (gibts nicht mehr unter Win64)

Hast du da eine Quelle zu?

Bei MS stehts so (FAQ for Development on 64-bit Windows, ODBC 64-Bit Information):

Zitat:

Zitat von FAQ for Development on 64-bit Windows

# Are ODBC or OLE DB supported in 64-bit Windows?

Yes, both ODBC and OLE DB are supported in 64-bit editions of Windows.

For more information, please see the ODBC 64-Bit Information in the MSDN Library.

The Microsoft OLE DB Core Services and the Microsoft SQL Server OLE DB Provider has been updated to support 64-bit Windows. These updates involve several API changes. If you are porting 32-bit OLE DB code to 64-bits, you will need to make changes to your code. Several new typedefs have been defined in the OLE DB header file. These new types allow you to maintain one set of source code for both 32-bit and 64-bit platforms. The simplest way to ensure that your code will compile in either 32-bit or 64-bit environments is to make sure that the code uses these new typedefs for variable definitions.

For more information, please see the What is a decorated device driver and how do I decorate my device drivers to get them to install?

An INF section is considered to be decorated when its name contains a TargetOSVersion suffix that identifies a particular platform and operating system. Decorated sections contain installation information that is relevant only to the platform and operating system specified by TargetOSVersion. If the device driver uses INF files for installation and the driver is not decorated, the driver will not install. Please check the INF files of third party devices and make sure the INF files have been decorated.

For more information, please see the article INF Requirements for 64-bit Systems.

[Bernhard Geyer]

Zitat:

Zitat von Flocke

Zitat:

Zitat von Bernhard Geyer

- ODBC ist eh Auslaufmodell (gibts nicht mehr unter Win64)

Hast du da eine Quelle zu?

Sowei ich mich erinnere hab ich das mal auf einer EKON-Konferenz gehört.
Aber falls es nicht "ausläuft" ist mir das auch egal. Nativer gehts viel Problemloser.

[Nightfly]

Was bedeutet nativ?

Ich habe nicht soviel Ahnung von der hohen schule des Programmierens...damit wir uns nich zu Falsch verstehen: Wenn sich der Änderungsaufwand in grenzen hält würde ich das Prog für jede DB auch etwas anpassen und neu compilieren.

Ganz dumm gesagt: Is SQL nich n Standard mit dem ich jede DB ansprechen können sollte? Ist das nicht auch ne gewisse Abstraktionsschicht?

Stelle ich mir das zu einfach vor wenn ich sage: Verbinde dich mit dem DB Server bei <Adresse>, logge dich mit <Benutzername, PW> ein und beschieße den Server mit <SQL Statement>?

[Bernhard Geyer]

Zitat:

Zitat von Nightfly

Was bedeutet nativ?

Das man direkt ohne allgemeine Zwischenschichten wie ADO, BDE oder ODBC direkt auf die DB zugreift. Hat den vorteil das weniger Zwischenschichten auch weniger Probleme bedeutet. Auch kommt man teilweise komplett ohne DB-Client-Installation aus.

Zitat:

Zitat von Nightfly

Ganz dumm gesagt: Is SQL nich n Standard mit dem ich jede DB ansprechen können sollte? Ist das nicht auch ne gewisse Abstraktionsschicht?

Der SQL-Standard deckt vieleicht 90/95% der Features einer DB ab. Alles was nicht im SQL-Stanard definiert ist oder "schwamig" wird mit sicherheit bei 2 Datenbanken auf 3 verschiedene Arten syntaktisch gelößt werden.[/quote]

[Nightfly]

kätzerisch gefragt: und wenn ich breit bin auf diese 5 - 10% zu verzichten?

[Elvis]

Zitat:

Zitat von Nightfly

kätzerisch gefragt: und wenn ich breit bin auf diese 5 - 10% zu verzichten?

Wirst du nicht immer können...

• Oracle vor Version 9 konnte noch keine ANSI SQL Joins, dort hieß es "A(+) = B" (Wobei die Seite mit dem (+) leer sein darf)
• Der SQL Server verwendet das @-verseuchte TSQL, welches nicht nur hässlich (IMHO) sondern auch absolut inkompatibel zu allem is, was sich DBMS nennt.
  Wie willst du filtern ohne Parameter und somit ohne @? ;)
• plus 5.000 andere Sachen über die sich der DB-geplagte Entwickler wohl 4.9998-mal am Tag aufregt...

[Bernhard Geyer]

Zitat:

Zitat von Nightfly

kätzerisch gefragt: und wenn ich breit bin auf diese 5 - 10% zu verzichten?

Nur wenn du sehr einfache Anwendungen schreibst sonst kann ich nur Elvis zustimmen.

Die Hersteller sind sehr darauf bedacht mittels spezielle SQL-Features das Anti-Pattern Ventor-Lockin zu betreiben. Denn einmal fest an eine DB gebunden bekommt man sie nicht so einfach wieder los. Also wenn möglich gleich DB-Neutral programmieren.

[sir-archimedes]

Oder du greifst zu einem Framework, mit dem Datenbankunabhängigkeit relativ schnell und einfach zu erreichen ist, wie z.B. RemObjects in Verbindung mit DataAbstract von RemObjects (http://www.remobjects.com).

Das ist zwar nicht ganz billig, soll aber sehr gut sein.

[Lemmy]

Hi,

SQL sprechen zwar alle SQL-Datenbanken, das bringt aber auch nichts, so lange die Datenbank die SQL-Statements nicht empfängt. Dazu braucht man nun mal Komponenten, oder du sprichts die API direkt an, was aber auch wieder bei den DBs unterschiedlich geht.

Eine DB-Abstratktionsschicht zu machen ist nicht wesentlich aufwändiger als ohne zu programmieren, allerdings kommt es sehr auf deine Anwendung an: Wenn Du eine Objektorientierte Struktur hast (d.h. eine Klasse TAdresse), dann macht das schon Sinn. Wenn Du aber mit datensensitiven Komponenten arbeitest, dann bringt dir die Abstraktionsschicht erst mal nichts, bzw. es ist ein höherer Aufwand notwendig.

Zu Paradox: Auch ich wurde hier in meiner neuen Arbeitsstelle "genötigt" mit Paradox und der BDE zu arbeiten (ein neues Produkt zu entwickeln). Nach 4 Monaten diskutierens hatte ich die Leute endlich so weit, dass wir die BDE über Bord geworfen haben und zu TurboDB gewechselt sind. Der Wechsel war an einem Tag erledigt! Vielleicht solltest Du dir deshalb nicht so viele Gedanken über die BDE machen und schon gar nicht über Delphi 5.

Grüße
Lemmy

[sir-archimedes]

Die Aussagen meines Vorredners kann ich nur unterstreichen. Ich habe bis zu meinem Update auch ausschließlich mit Delphi 5 gearbeitet. Meines Erachtens ist Delphi 5 für Win32-Anwendungen genauso gut geeignet, wie ein aktuelles Delphi. Die Umstellung eines Projektes von Delphi 5 auf D2006 ist bei mir völlig problemfrei gegangen.

[Bernhard Geyer]

Zitat:

Zitat von Lemmy

Zu Paradox: Auch ich wurde hier in meiner neuen Arbeitsstelle "genötigt" mit Paradox und der BDE zu arbeiten (ein neues Produkt zu entwickeln). Nach 4 Monaten diskutierens hatte ich die Leute endlich so weit, dass wir die BDE über Bord geworfen haben und zu TurboDB gewechselt sind. Der Wechsel war an einem Tag erledigt! Vielleicht solltest Du dir deshalb nicht so viele Gedanken über die BDE machen und schon gar nicht über Delphi 5.

Mich würde Interessieren was für Argumente man noch in 2005 vorbringen kann um mit BDE und Paradox eine neues Programm zu entwickeln.

[Lemmy]

Zitat:

Zitat von Bernhard Geyer

Mich würde Interessieren was für Argumente man noch in 2005 vorbringen kann um mit BDE und Paradox eine neues Programm zu entwickeln.

Ich war jung und brauchte das Geld ;-)

Ganz einfach: Zum einen lief die bestehende Applikation seit 5 Jahren stabil mit der BDE, sie waren der Ansicht, dass für kleine Nachschlagetabellen die BDE vollkommen ausreichend wäre und dass sie genug Erfahrung mit der BDE haben um alle Probleme zu beseitigen.

Die Applikation die ich entwickelt habe, speichert die Projektdaten in XML-Files, die BDE / Paradox wurde nur dazu verwendet Stammdaten zu verwalten. Es gab also keine großen Datenmengen, aber mit XML hatten wir zu wenig Erfahrung um auch diese Daten gleich von Anfang an in einer XML-DB zu speichern.

Während der Entwicklung habe ich mehrere Anläufe genommen, um die BDE zu ersetzen, bin aber immer bei meinem Arbeitgeber nicht weitergekommen.
Allerdings hat es in der ersten Betatestwoche bei 2 Kunden die Paradox-Netzwerkeinstellung zerblasen, so dass schließlich auch er eingesehen hat, dass die BDE nichts mehr bringt, außer vielleicht Probleme. Der Umstieg auf TurboDB war wie gesagt an einem Tag erledigt.

Grüße
Wolfgang

[Nightfly]

Naja, es ist schon frustrierend, wenn man an der Studieneinrichtung vom neuesten Zeug hört (zumindest bei einigen Dozenten) und dann mit Tools von gestern entwickeln muß.
:-/

Hab mir jetzt mal Visual Studio Enterprise gezogen...ma schauen was damit geht...