|
Anzeige
|
Gemeinsamkeiten bi ODBC-Treibern
Gast
#2563405
Hallo Freunde der PC-Programmierung, kann mir jemand sagen, ob ODBC soweit abstrahiert ist, so dass man eine gemeinsame Abfrage-Grundlage hat? Also ist z.B. "SELECT spalte FROM tabelle WHERE spalte='wert'" in allen Treibern gleich, oder hat das gar nichts miteinander zu tun? Viele Grüße, Peter
Gast
#2563413
Einfache Abfragen funktionieren in der Regel recht gut mit unterschiedlichen Datenbanken, aber das liegt eher daran, dass die Datenbanken diese SQL Statements direkt verstehen. Wenn man natürlich Datenbank-Spezifische Sachen verwendet (Oracle-Sequences, Firebird-Generatoren etc), dann kann das der Treiber nicht umsetzen.
Gast
#2563441
ja, das mit dem recht gut ist mir auch bewusst. aber gibt es eine fixe gemeinsamkeit zwischen allen?
Gast
#2563464
Peter schrieb: > Also ist z.B. "SELECT spalte FROM tabelle WHERE spalte='wert'" in allen > Treibern gleich, oder hat das gar nichts miteinander zu tun? das hat nichts mit ODBC zu tun. ODBC reicht alles abfrage 1:1 an den DB durch. ODBC legt nur die API fest nicht den sprachumfang. Was du sucht ist SQL92, oder SQL99 oder TSQL
Gast
#2563471
Die ganze ODBC Sache kommt aus der grauen Computer-Vorzeit und wird aus Kompatibilitätsgründen wohl noch mitgeschleppt. Ich kenn das schon seit NT4 Zeiten, und es hat immer nie so richtig zufriedenstellend funktioniert. Der Grundgedanke, dass man auf diese Art die unterschiedlichen Datenbanken gleich ansprechen kann, ist zwar gut und schön, hat aber in der Praxis nie so richtig funktioniert. Wenn Du also nach fixen Gemeinsamkeiten fragst, kann ich nur sagen: Es ist langsam (teilweise Faktor 10) und macht Probleme. Gleichwohl ich es für manche Sachen trotzdem einsetze, da es bisweilen nützlich ist. Grössere Sachen mache ich aber mit Native Treibern oder ado/.Net
Gast
#2563476
Dr. G. Reed schrieb: > Es ist langsam (teilweise Faktor 10) und macht Probleme. odbc hat sogut wie keine einfluss auf die Geschwindigkeit. Es ist nur ein Wrapper auf die dlls der Datenbank. Es werden eigenlicht alle ODBC aufrufe an die passene dll weitergeleitet. woher soll hier eine geschwindigkeitsunterschied kommen? Meist sind die leute nur nicht in der lage die Variabel ordentlich zu binden oder mit Prepared statement zu arbeiten. Über ODBC schafft man es auch das das Netzwerk zum flaschenhals wird wenn die Datenbank schenll genug ist.
Gast
#2563499
Peter II schrieb: > das hat nichts mit ODBC zu tun. ODBC reicht alles abfrage 1:1 an den DB > durch. Das ist genau die Aussage, die ich gesucht habe, allerdings auch wieder irgendwie in Frage stellen muss :-( Es gibt doch z.B. auch ODBC-Treiber (Standard in Windows), die auf Textdateien zugreifen können. Und da wird soweit ich weiß auch mit SELECT gearbeitet. Also muss doch etwas mit dem Statement im ODBC-Treiber passieren. Gibts hier Belege im Internet, wie das genau funktioniert? Naja, geben wirds die schon. Also dann eher: kennt jemand gute Links dazu? Viele Grüße, Peter
Gast
#2563520
Peter schrieb: > Es gibt doch z.B. auch ODBC-Treiber (Standard in Windows), die auf > Textdateien zugreifen können. Und da wird soweit ich weiß auch mit > SELECT gearbeitet. Also muss doch etwas mit dem Statement im > ODBC-Treiber passieren. ja und nein. ODBC reicht alles an den Text-ODBC treiber weiter. Dieser versteht dann das SQL. Damit ist im Treiber eine kleine DB die mit den Textdateien arbeitet. An dieser Stelle interpretiert also der Treiber die Befehle, odbc reicht es auch hier nur durch. Um es mal verständlicher zu machen: wenn Peter II schlichtweg von ODBC spricht, dann meint er eigentlich den ODBC-Drivermanager. Denn das ist derjenige, der die ODBC-API-Calls der Anwendungen empfängt. Die ODBC-Anwendung redet eigentlich gar nicht direkt mit dem jeweiligen ODBC-Treiber, sondern eben mit dem Treiber-Manager, der praktisch wie ein Router fungiert. An den Drivermanager kann man dann die unterschiedlichsten Treiber der Datenbankprogramme andocken (Treiber+Datenbank registrieren). Je nach angesprochenen DB Alias (auf API-Ebene Connectionhandle) routet der Manager dann die API-Aufrufe der Anwendung an den jeweiligen Treiber weiter. An der Stelle zw. Treiber und Treibermanager hat man dann eine CLI-Schnittstelle (Call Level Interface), die man quasi als Vorläufer von ODBc bezeichnen (ODBC ist eigentlich nur eine zusätzliche Schicht obendrauf, um die Router-Funktionalität mit reinzubringen, was von MS eigentlich keine schlechte Idee war). Was man letztendlich für SQLs in den API-Aufrufen verschickt, ist eigentlich wurscht, denn idR. interessiert sich der Treiber nicht dafür, was da so hin- und herflutscht, es sei denn, man nutzt sogenannte ODBC-Escape-Sequenzen, die gewisse Anweisungen für den Treiber darstellen, oder der Treiber enthält gewisse Optimierungen für gewisse SQL-Konstrukte. Wenn Du willst, könntest Du deine eigene SQL-Sprache entwickeln, und über ODBC verschicken. Brauchst dann nur noch eine Datenbank, die dieses "SQL" auch versteht ;-) Der ODBC-Treiber soll eigentlich nur die ODBC-API-Calls auf das native DB-API umsetzen, so daß sich die Anwendung nicht mit den Eigenheiten jeder x-beliegbigen DB auseinandersetzen muß. Der angesprochen Text-Treiber ist eigentlich ein Zwitter - Datenbank und Treiber zugleich.
Gast
#2846863
...hier habe ich eine kurze, befriedigende und passende Antwort auf meine Frage gefunden: http://msdn.microsoft.com/en-us/library/ms711725(v=vs.85).aspx Viele Grüße, Peter Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
