Datenbankzugriff in verschiedenen Programmiersprachen

[ESAD]

Ich bräuchte Informationen über den Datenbankzugriff in verschiedenen Programmiersprachen hiermit meine ich C# mit Framework 2.0, PHP 4.0 und Java 1.5
Interessieren würde mich neben dem programmcode auch der technische hintergrund weil c# funktioniert ja das meiste über die oledb treiber? wie geht das in java? ist es in php überhaupt möglich etwas weiter in die materie einzusteigen?
Danke
mfg
ESAD

[transstilben]

Hm, wie wärs mit einem Versuch bei WIKIPEDIA zum Thema "odbc" oder "jdbc" ?
In java braucht man im Prinzip einen "JDBC"-Treiber der dann die ODBC-Schnittstelle bedient.

Vermutlich findest du dort auch verständliche Info's wie ODBC funktioniert.

http://de.wikipedia.org/wiki/ODBC
http://de.wikipedia.org/wiki/JDBC

[Gast]

um da eine antwort geben zu können, wäre die nennung der datenbank, auf die zugegriffen werden soll aber durchaus ausschlaggebend, z.b. ist das connection von oracle und mysql unter php gleich, das handling kann aber große unterschiede aufweisen.

[Ganon]

In java braucht man im Prinzip einen "JDBC"-Treiber der dann die ODBC-Schnittstelle bedient.

Öhm, JDBC nutzt ODBC nur, wenn kein nativer JDBC-Treiber da ist. Ansonsten kapselt JDBC die C-Lib der Datenbank, oder spricht die Datenbank direkt an.

[transstilben]

Öhm, JDBC nutzt ODBC nur, wenn kein nativer JDBC-Treiber da ist. Ansonsten kapselt JDBC die C-Lib der Datenbank, oder spricht die Datenbank direkt an.

Ja. Und ? Ich sehe das ganze aus einer praktischen Perspektive. Dabei sind dann Details egal (Black Box Prinzip ;) )

[Shink]

Ja. Und ? Ich sehe das ganze aus einer praktischen Perspektive. Dabei sind dann Details egal (Black Box Prinzip ;) )
Dann ist doch die Aussage, dass JDBC ODBC verwendet, noch größerer Käse.

- viele (alle?) Datenbanken kann man über Kommandozeile bedienen - daraus kann man sich einfach mit jeder Programmiersprache einen Treiber basteln.

- man kann Datenbanken "direkt" über deren API/Libraries ansprechen. So eine Library könnte ein DB-Hersteller für alle möglichen Programmiersprachen machen, macht man aber meist nicht; schließlich kann man ja C-Libraries auch mit anderen Sprachen befummeln. Nachteil: Theoretisch hat man für jede DB ein anderes Handling.

- ODBC: Eine Art Zwischenschicht: DB-Hersteller stellen ODBC-Treiber bereit, für die Programmiersprache gibt es ebenfalls eine ODBC-Schnittstelle. Das ganze ist allerdings leicht M$-behaftet, wenn es auch inzwischen offen ist und in anderen Betriebssystemen funktioniert. So funktioniert DB-Zugriff z.B. mit einem .NET-Framework.

- JDBC: Eine andere Zwischenschicht: DB-Hersteller stellt JDBC-Treiber bereit, JDBC ist Teil jeder Java Standard-Auslieferung. Klingt eigentlich weniger sinnvoll, funktioniert aber sehr gut auf allen möglichen Geräten von PDA bis Mainframe, ist weniger tief im Betriebssystem verankert und da Oracle und IBM nun mal Java-Freunde sind und es ein paar moderne Pure-Java DBs gibt, wird so etwas wirklich oft verwendet.

[transstilben]

Dann ist doch die Aussage, dass JDBC ODBC verwendet, noch größerer Käse.


Hm, ich bin kein Experte was JDBC angeht. Dennoch halte ich die Aussage die bei WIKIPEDIA gemacht wird (http://de.wikipedia.org/wiki/JDBC) bzgl. Type-1-Treiber für richtigt, Zitat :

"Ein JDBC-Typ-1-Treiber kommuniziert ausschließlich über einen JDBC-ODBC-Bridge-Treiber. Die bekannteste JDBC-ODBC-Bridge ist die von Sun vertriebene. Damit ist ein Typ-1-Treiber abhängig von einem installierten ODBC-Treiber. Der JDBC-ODBC-Bridge-Treiber wandelt JDBC- in ODBC-Anfragen um."

Wir wollen uns doch hier nicht etwa in Haarspaltereien verstricken, wie das Wort "Treiber" in diesem Kontext zu definieren ist, oder ? Ich würde vorschlagen ab nun "Back to topic".

[Gnafoo]

[...]- ODBC: Eine Art Zwischenschicht: DB-Hersteller stellen ODBC-Treiber bereit, für die Programmiersprache gibt es ebenfalls eine ODBC-Schnittstelle. Das ganze ist allerdings leicht M$-behaftet, wenn es auch inzwischen offen ist und in anderen Betriebssystemen funktioniert. So funktioniert DB-Zugriff z.B. mit einem .NET-Framework. [...]

Bei .NET funktioniert der Datenbankzugriff erstmal über ADO.NET (http://de.wikipedia.org/wiki/ADO.NET), eine Sammlung von Klassen im .NET-Framework. Diese stellen eine einheitliches Interface zur Verfügung um verschiedene Datenbanken zu benutzen.

Dafür werden Provider genutzt, welche zwischen ADO.NET und der Datenbank vermitteln. Es gibt unter anderem einen ODBC-Provider. Der ist aber afaik recht langsam und eher ein Relikt aus alten Zeiten. Besser ist es, wenn man für die Datenbank (MsSQL, MySQL, Oracle, ...) einen eigenen ADO.NET-Provider hat (für einige Datenbanken ist dieser schon dabei, wie z. B. Oracle und MsSql. Für andere bekommt man die einzeln z. B. MySQL (http://www.mysql.org/downloads/dotnet.html)). Dort ist der Zugriff dann auch recht performant möglich.

Übrigens hat sich mit dem .NET-2.0-Framework im Vergleich zur 1.x-Version bezüglich ADO.NET wohl eine Menge getan, was die Performance angeht.

[darph]

Bei .NET funktioniert der Datenbankzugriff erstmal über ADO.NET (http://de.wikipedia.org/wiki/ADO.NET), eine Sammlung von Klassen im .NET-Framework. Diese stellen eine einheitliches Interface zur Verfügung um verschiedene Datenbanken zu benutzen.
Wie mach ich das eigentlich am Dümmsten in C#? Die Datenbankverbindung in ein Singleton packen und da dann Methoden wie public Product[] getProductsByPriceRange(double min, double max) basteln?

Oder wie geht man sowas an? Hier speziell mit SQLite

[UliBär]

Hm, ich bin kein Experte was JDBC angeht. Dennoch halte ich die Aussage die bei WIKIPEDIA gemacht wird (http://de.wikipedia.org/wiki/JDBC) bzgl. Type-1-Treiber für richtigt, Zitat :

"Ein JDBC-Typ-1-Treiber kommuniziert ausschließlich über einen JDBC-ODBC-Bridge-Treiber. Die bekannteste JDBC-ODBC-Bridge ist die von Sun vertriebene. Damit ist ein Typ-1-Treiber abhängig von einem installierten ODBC-Treiber. Der JDBC-ODBC-Bridge-Treiber wandelt JDBC- in ODBC-Anfragen um."

Wir wollen uns doch hier nicht etwa in Haarspaltereien verstricken, wie das Wort "Treiber" in diesem Kontext zu definieren ist, oder ? Ich würde vorschlagen ab nun "Back to topic".Äußerst geschickt zitiert, nur hast Du natürlich das wichtigste, welches nicht in Deine Theorie paßt, weggelassen:
Typ-1-Treiber
Ein JDBC-Typ-1-Treiber kommuniziert ausschließlich über einen JDBC-ODBC-Bridge-Treiber. Die bekannteste JDBC-ODBC-Bridge ist die von Sun vertriebene. Damit ist ein Typ-1-Treiber abhängig von einem installierten ODBC-Treiber. Der JDBC-ODBC-Bridge-Treiber wandelt JDBC- in ODBC-Anfragen um.
Ein Typ-1-Treiber wird dann verwendet, wenn es zu der Datenbank keine eigenständigen JDBC-Treiber gibt.Normalerweise werden Typ 1 Treiber nur als Übergangs- oder Notlösung verwendet. Wenn es für eine Datenbank keinen nativen JDBC-Treiber gibt, nimmt man halt eine andere. :cool:

[Gnafoo]

Wie mach ich das eigentlich am Dümmsten in C#? Die Datenbankverbindung in ein Singleton packen und da dann Methoden wie public Product[] getProductsByPriceRange(double min, double max) basteln?

Oder wie geht man sowas an? Hier speziell mit SQLite
Tja so ganz genau kann ich dir das mit meinem Halbwissen leider auch nicht sagen und es hängt vermutlich auch etwas vom konkreten Fall ab, von daher gebe ich die Frage mal weiter und schau mal, ob jemand mehr weiß. :biggrin:

Es ist aber auf jeden Fall so, dass man sich vom Datenbank-Provider ein Factory-Objekt holen kann und damit Command-Objekte etc. erstellen kann, mit denen man SQL-Abfragen und Stored Procedures ausführen kann, Transaktionen bilden kann etc. Das ist an sich erstmal weitestgehend unabhängig vom Datenbanktyp. Was allerdings afaik Probleme machen kann sind leichte Unterschiede in den SQL-Dialekten, der Benennung von Parametern bei Stored Procedures o. ä. Da könnte ich mir vorstellen, dass es sich evtl. lohnt selber ein wenig zu abstrahieren. Es sei denn man legt sich auf eine Datenbank fest.

Aber es ist auf jeden Fall nicht so, das verschiedene Datenbanken verschiedene APIs erfordern.

[Wuzel]

Wie mach ich das eigentlich am Dümmsten in C#? Die Datenbankverbindung in ein Singleton packen und da dann Methoden wie public Product[] getProductsByPriceRange(double min, double max) basteln?

Oder wie geht man sowas an? Hier speziell mit SQLite

Einen Wrapper für das C(++) Interface nehmen oder selbst schreiben.

Doch Achtung(!) native Aufrufe sind verdammt teuer in .NET -> ich würde die ganze DB Geschichten in C++ packen und dann mit einem Wrapper ein kleines Interface zu den Daten einrichten.

Alternative C/S über Pipe -> bei SQLite3 allerdings nicht sooo der Hit.

[Demirug]

Einen Wrapper für das C(++) Interface nehmen oder selbst schreiben.

Doch Achtung(!) native Aufrufe sind verdammt teuer in .NET -> ich würde die ganze DB Geschichten in C++ packen und dann mit einem Wrapper ein kleines Interface zu den Daten einrichten.

Alternative C/S über Pipe -> bei SQLite3 allerdings nicht sooo der Hit.

Wobei man solche Wrapper nach Möglichkeit besser mit C++/CLR als mit C# schreibt.

[Shink]

Ich bin zwar der, der nicht weiß, dass man mit .NET kein ODBC mehr braucht, würde aber trotzdem mal ausprobieren, was andere zusammengebastelt haben - immerhin besteht die Chance, dass man es selbst nicht besser hinbekommt:
http://sourceforge.net/projects/sqlite-dotnet2/