Was sind native DB-Komponenten?

[ak1]

Hallo Leute,

was sind native DB-Komponenten? Was ist das Gegenstück dazu und wo liegen die Unterschieden, Gemeinsamkeiten, Vor- und Nachteile?

[Bernhard Geyer]

Native DB-Komponenten sind Komponenten welche auf die primäre Zugriffsschnittstelle einer Datenbank aufsetzen, ohne den Umweg über allgemeine Schnittstellen zu gehen.

Der Zugriffsweg Anwendung -> BDE -> ODBC -> MySQL-ODBC-Treiber -> MySQL-Datenbank ist z.B. eine nicht nativer Zugriffsweg

Dageben ist z.B. der Weg Anwendung -> Zeos-Lib (Als Beispiel) -> libmysql.dll -> MySQL-Datenbank ein native-Weg

Noch nativer wäre z.B. Anwendung -> Corelabs-MySQL-Treiber -> MySQL-Datenbank.

Der Vorteil des nativen Zugriffsweg ist:
- Minimale Zwischenschichten welche evt. gesonderte zu installieren wären
- Minimierte Fehlerquellen (jede Zwischenschicht kann Implementierungsfehler enthalten)
- Optimaler Funktionsausnutzung. Jede Zwischenschicht kann die Verwendung von DB-Details (wie z.B. nvarchar-Felder, Bitfelder, Sondertypen,...) verhindern.
- Optimale Performance. Jede Zwischenschicht kann zu Einbußen in der Geschwindigkeit führen.

[Hansa]

native Komponenten können direkt auf die DB bzw. auf das zugrunde liegende API zugreifen. Die BDE ist also das Gegenteil davon.

[ak1]

gut zu wissen. Danke für die Aufklärung.

[Alfons_G]

Wobei ich gerade bei kommerziellen Anwendungen die Komponenten von Core Lab (für Oracle, MS SQL Server und MySQL) wärmstens empfehlen kann. Der Zugriff ist um Längen schneller, als bei BDE, ODBC und auch ADO. Die Kompos sind knapp, aber ausreichend dokumentiert und werden seit Jahren vom Hersteller weiterentwickelt.
Testversionen gibt es bei Torry. Die Vollversionen kann man für 70 - 350 Euro bei Share-it in Köln beziehen. Das Preis-Leistungs-Verhältnis ist sehr gut.

Für Freeware-Programme gibt es auch brauchbare Gratis-Komponenten bei Torry. Allerdings ist hier der Arbeitsaufwand höher.

:coder:

[woki]

Hi,

nach den bisherigen Antworten könnte man sich fragen, wieso es dann überhaupt nicht native Zugriffswege gibt:

Das wichtigste Ziel ist, die Anwendung nicht ein- für allemal an eine Datenbank zu ketten, sondern durch Einführung dieser Zwischenschicht einen einfachen Wechsel der Datenbank ermöglichen zu können.

Woki

[Bernhard Geyer]

Zitat:

Zitat von woki

Das wichtigste Ziel ist, die Anwendung nicht ein- für allemal an eine Datenbank zu ketten, sondern durch Einführung dieser Zwischenschicht einen einfachen Wechsel der Datenbank ermöglichen zu können.

Diesen Vorteil können aber Zwischenschichten wie BDE und ADO nicht 100%ig leisten. Dazu erfolgt auf dieser Zwisschenebene eine zu geringe Abstraktion des SQL-Dialekts.
So ist z.B. nicht möglich die SQL-Anweisung SELECT TOP 10 FROM MyTABLE ohne Anpassungen auf jede beliebige DB umzusetzen.

Nicht umsonst ist M$ mit ADO.NET einen anderen Weg gegangen und hat für jeden Zugriff auf eine andere Datenbank spezialisierte DB-Zugriffskomponenten eingeführt und nur der DB-Unabhängie Teil wird mittels allgemeinger Dataset-Komponenten gehandhabt.

Auch unter Delphi kann man mit Hilfe der TDataset-Basisklassen trotz Verwendung von nativer-Komponenten eine DB-unabhänige Anwendung schreiben. Dazu muss man "nur" das Bridge-Pattern verwenden, um die eigenheiten der DB's und der SQL-Dialekte zu kapseln.

[Robert_G]

Zitat:

Zitat von Woki

...Das wichtigste Ziel ist, die Anwendung nicht ein- für allemal an eine Datenbank zu ketten...

In dem Fall kann man aber keine der Speziellen Features einer DB verwenden!
Ich zum Beispiel arbeite viel mit OOP innerhalb von Oracle, deshalb nutze ich auch den Object cache des Ora Clients um unnötige Netzwerk-Roundtrips zu vermeiden.
Diese Geschichten kann ich in D7 nur über DOA oder direkt mit OCI lösen, bzw. mit dem ODP.Net unter D8.
Ich habe mich also an eine DB gekettet, da es mit keiner Zwischenschicht möglich ist das auch auf anderen DBs zu nutzen.