Datenbank Abstraktionsschicht

[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 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 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 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 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 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 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