Database Provider.....

[Summoner]

Hallo liebes (Programmier)Forum!

Ich bin selbst auch Programmierer und habe schon hier und da auch mit Datenbanken zu tun gehabt.

Trotzdem (obwohl ich sie laufend verwende) sind mir verschiedene Dinge über "Data Providers" und Driver nicht ganz klar.

Was genau "tut" ein ODBC Driver... warum muss ich ODBC Treiber im System installieren um auf eine Datenbank per ODBC zugreifen zu können? Und warum habe ich daher im Control-Panel meine "ODBC Datasources"... nicht aber z.B. "OLE Datasources" oder "SQL Datasources"?

Was macht also der Provider/Treiber? (Unterschied?) und wieso kann ich nicht "direkt" zu einer DB verbinden ohne noch irgendwelche Treiber (z.B. den AS/400 Treiber o.Ä.) zu installieren?

Ich weiß, das sind vieeeele Fragen, aber irgendwie brennen sie mir schon ewig auf der Seele und das obwohl ich recht gut Datenbank-designe... bloß wenn's dann um's connecten geht, strauchel ich meistens -> bzw. weiß einfach nicht so im detail WAS ich tu, auch wenn ich in der Regel weiß WIE ich es tun muss...

Also fröhliches Diskutieren!

lg Wolfgang

[delphirocks]

ODBC/JDBC/OLEDB usw. sind nur Schnittstellenspezifikationen.

Ein Datenbanktreiber implementiert die Schnittstelle. Wenn du z.B. "connect", "select", o.Ä. aufrufst, muß dieser Aufruf über irgendein Protokoll an den Server übermittelt werden (z.B. Oracle Net8 über Tcp/IP o.Ä.). Am Server läuft ein Listener Prozess, der auf Anfragen wartet und dann entsprechend reagiert.
Wenn du keinen Treiber hättest, müßtest du das Protokoll (z.B.Net8) selbst implementieren. Das Protokoll und auch die Aufrufe sehen bei jeder Datenbank anders aus.
So öffnet ADOConnection.Open eine Verbindung zur DB, egal ob's eine Oracle oder eine MySql ist. Wie der Aufruf dann aussieht (OCI_CreateSession oder mysql_connect, o.ä.), kann dir dann als Anwendungsentwickler egal sein.
- Um das muß sich der Hersteller kümmern, der kennt sein Protokoll ja auch am besten...

[Biri]

hi,

den bereits guten erklärungen möchte ich noch hinzufügen:

Was genau "tut" ein ODBC Driver

Eine datenbankneutrale Programmierschnittstelle bereitstellen. Du programmierst dann gegen die Funktionen des ODBC Treibers, nicht gegen die DB selbst. Ist als einfach eine höhere Abstraktionsebene.

wieso kann ich nicht "direkt" zu einer DB verbinden

Kannst du und es gibt auch sog. native Treiber.
Vorteil: Schneller als ODBC, Nützung datenbankspezifischer Funktionen möglich.
Nachteil: Wenn sich die DB ändert, müssen alle Programmteile, die etwas mit DB machen auch geändert werden.

frag nur - das hatt noch keinem geschadet.

fg
-hannes

[Summoner]

Sososo

Danke für die Antworten!!

Das heißt also z.B. wenn ich von meinem (.net) Programm aus auf eine Datenbank zugreifen möchte habe ich prinzipiell immer zwei Möglichkeiten:

Entweder ich installiere den ODBC-Treiben vom DB-Hersteller auf meinem Computer und kann dann über ODBC standardisiert auf die DB zugreifen.

Oder ich organisiere mir lieber einen nativen Treiber (aber ebenfalls vom DB Hersteller), der schneller ist.

Wie sieht denn so ein nativer Treiber aus? Das ist einfach eine DLL (Assembly), auf die ich in meinem Code referenziere, oder? Also z.B. einfach "System.Data.SQLClient"... oder (ich glaube den gibt es zwar nicht, aber) "IBM.AS400Client".

Richtig?

So einen nativen Treiber muss ich nicht so im System verankern wie einen ODBC-Treiber, oder?

Endlich ein wenig Licht in die Sache gebracht Danke!

[delphirocks]

Hallo,

Der native Treiber selbst ist eine Assembly, die du referenzierst. Ob zusätzliche Clientsoftware installiert werden muß, hängt von der Art des Treibers ab. Es gibt Treiber, die die komplette Kommunikation in C# implementieren ("thin driver"). Dann brauchst du außer der Assembly keine zusätzliche Clientsoftware mehr zu installieren.

Bei einem "thin driver" wird die gesamte Connection-Info beim Aufruf mitgegeben.
z.B. connect("server=192.168.10.1;sid=ORA817;user=xx;pa ssword=xxx").

Für dich als .NET Programmierer besteht kein Unterschied, ob hinter deinem ADO.NET Interface ein ODBC Aufruf steht oder sonstwas.

ODBC war der erste Versuch, eine einheitliche Schnittstelle zu schaffen, deswegen kann man auch davon ausgehen, daß zu ziemlich jedes DB-Tool ODBC in irgendeiner Form unterstützt.
So kannst du z.B. mit Oracle's SQL Plus über ODBC auf MSAccess zugreifen....

Wie der ODBC Mechanismus genau funktioniert, ist mir allerdings auch nicht ganz klar. Ich denke irgendwo in der Registry muß der DSN-Eintrag zum dahinterliegenden Treiber gemapped werden...

[Biri]

hi,

Bei .net Programmierung würde ich versuchen, IMMER einen native Treiber zu verwenden. Alle bekannteren DB Hersteller bieten einen solchen an.
ODBC oder OleDB ist eine "Notlösung", wenn es keinen native Treiber gibt. .net erzeugt dann ein Interop Assembly um auf den unmanaged DB Treiber zuzugreifen.

prinzipiell immer zwei Möglichkeiten

odbc, oledb und native - also 3 möglichkeiten

So einen nativen Treiber muss ich nicht so im System verankern wie einen ODBC-Treiber

stimmt - wie bereits von delphirocks geschrieben, einfach referenzieren.

Dem ist noch hinzuzufügen: Im Idealfall sollte man den Vorteil "Datenbankunabhängigkeit" und "Verwendung eines native Treibers" natürlich kombienieren.
In .net solltest du auf DB Funktionalitäten daher wenn möglich über ein Interface zugreifen (Pattern: program against an interface, not an implementation).
Alle native Treiber implementieren diese Interfaces - z.B. IConnection.
Also Factory verwenden, die dir aufgrund von Parametern eine spezifische, DB abhängige Instanz zurückliefert.

das passt jetzt aber nimma ganz zum thema deiner anfrage...

fg
-hannes

[Summoner]

Vielen Dank euch allen! Jetzt bin ich wieder etwas klüger

Ahja... das mit der "Datenbankunabhängigkeit": Nachdem hier ja die Datenbank-Fachmänner grad versammelt sind:

Ist es euch denn schon einaml untergekommen, dass ihr z.b. von Oracle weg auf MS SQL oder sonstwie gewechselt habt? Auch wenn es freilich zum guten Ton gehört, schön über Interfaces und mit Factory-Klassen zu arbeiten: Ausgezahlt hat sich das (im DB-Bereich) bis jetzt für mich noch nicht. Außer dass mein Code schön aussieht und mir das Freude macht

Aber dass sich die DB ändert, wird wohl eher der Fall bei wirklich großen Projekten (Schlagwort "Enterprise-Development") sein. Bei "normalen" Projekten... also irgendwelchen Webshops oder Workflow-Lösungen eher nicht meiner Erfahrung nach.

lg Wolfgang

[Biri]

Ist es euch denn schon einaml untergekommen, dass ihr z.b. von Oracle weg auf MS SQL oder sonstwie gewechselt habt

ja.
damals wurden beide DBs über odbc angesprochen, Programm war in C++.
war teils recht problematisch, weil der odbc treiber memory leaks hatte...

Aber dass sich die DB ändert, wird wohl eher der Fall bei wirklich großen Projekten (Schlagwort "Enterprise-Development") sein. Bei "normalen" Projekten... also irgendwelchen Webshops oder Workflow-Lösungen eher nicht meiner Erfahrung nach.

Wenn ich die Entscheidung treffen kann (nicht der Kunde) und es ein kleines Projekt ist, würde ich mich für EINE DB entscheiden und dann auf diese abgestimmt programmieren.
Hat den Vorteil, dass man DB abhängige Features verwenden kann.

Wenn das Projekt umfangreicher ist, eine schöne Schichtenarchitektur (DB, Business Objects, GUI) hat bzw. haben sollte stellen sich natürlich andere Fragen - z.B. ob man ein Object Persistence Framework verwendet und so überhaupt nichts mehr/wenig mit der DB direkt zu tun hat.

Ist aber nur eine von vielen Fragen und "Fachmann" bin ich hier auch keiner.

fg
-hannes