Welche Datenbank für welches Einsatzgebiet?

[Alexander]

Hallo,
ich kenne mich ja leider noch nicht so gut mit Datenbanken aus. Immerhin hat es zwar auch schon für komplexere DB-Anwendungen gereicht, allerdings weiß ich nie, welche Datenbank ich verwenden soll und ob ich über ADO, BDE oder irgendwas auf die DB verbinden soll.
Könnt ihr vielleicht einmal ein paar Datenbanken und deren Eigenschaften/Einsatzgebiete aufzählen? Das könnte man vielleicht auch später in die Code-Lib verschieben...

Würde mich über ein paar Posts freuen
Alexander

[Bernhard Geyer]

Für kleiner zu erwartente Datenmenge bzw. Zugriff nur von einen (bzw. wenigen Usern) sollte man eine Lokaldatenbank wie ADS, Access, ... verwenden.

Hierbei empfehle ich z.B. ADS im Lokalbetrieb, da hierbei keine Installation nötig ist (nur 2-3 Dateien im Anwendungsverzeichnis).

Sind Aspekte wie Transaktionen, Verteilung auf mehrere Standorte, 24 Stunden-Verfügbarkeit mit Online-Backup nötig, so mußt du eine "richtige" SQL-Datenbank wie Oracle, MS-SQL, MySQL, ... verwenden.

Welche ist relativ egal. Jede hat m.E. Vor- und Nachteile.

MS-SQL ist z.B. relativ einfach zu verwalten, unterstützt jedoch nicht das Multi-Versions-Konzept.
MySQL unterstütz keine Serverseitigen-Curser (jedenfalls nicht bei den "normalen" Zugriffskomponenten, ist jedoch sehr günstig. Auch ist i.d.R. keine Clientinstallation nötig (wenn z.B. über libmysql.dll zugegriffen wird).
Oracle ist etwas komplizierte bezüglich Adminstration.

Falls man für eine Firma etwas entwickelt, ist es immer am besten die dort schon vorhandene DB zu verwenden.

[Robert_G]

Ich glaube Caché wird immer wieder gerne vergessen.
Die ist so ziemlich das schnellste, was ich bisher gesehen habe.
Für den Zugriff gibt es entweder ODBC (keine Sorge der ODBC-Treiber ist auch sackschnell ) , ObjektProjektion per COM oder eine Objektprojektion als C++ oder Java Klassen.
Ich weiß jetzt nicht wo sie preislich anzusiedeln ist (Darum muss ich mich zum Glück nicht kümmern), ich denke aber sie wird preislich dem SQL Server entsprechen.

Zitat:

Oracle ist etwas komplizierte bezüglich Adminstration.

Das ist allerdings wahr. Es ist aber möglich, dass sich eine OraDB zu 90% selbst administriert. Man muss es nur vernünftig programmieren. (systemweite Events gibt's ja genügend)
Ein zweifelhafter Vorteil von Oracle ist die Möglichkeit intern in PL/SQL oder Java zu programmieren. (Ich bin irgendwie allergisch auf Java )
BTW Ora kann fast alles: Es ist ein Webserver, MailServer, ApplicationServer,... achso es ist auch eine Datenbank.

Nachtrag:
upps: Es ging ja um das Einsatzgebiet:

Oracle ist in vieler Hinsicht ein klassisches relationales Data Warehousing Arbeitstier.
Es machen sich auch mehrere 100/1000 gleichzeitige Sessions kaum bemerkbar. Die wirkliche Stärke liegt in der IMHO wunderbar für DB-interne Zwecke passende Sprache PL/SQL. Dadurch ist Oracle geradezu geschaffen für aufwendige Datenvalidierungen (weshalb ich es hauptsächlich verwende)

Caché ist mehr eine objektorientierte KickAss Highperformance DB, die sich vorzüglich als Basis für Webservices macht.
Es gibt mit CSP (Caché Server Pages) auch ein Gegenstück zu ASP, dabei ist die DB auch der Webserver.
ABER: Caché ist _anders_ . Ich komme mir selbst nach einem Monat mit Caché noch vor wie ein DB-Newbie.
Zum Bleistift: Tabellen sind Collections persistenter Klassen, die u.A. auch Mehrfachvererbung unterstützen.

[UweR]

Hallo,

als SQL-datenbank sollte man auch noch Interbase bzw. Firebird erwähnen, ist günstig da OpenSource und mit Delphi kann gut drauf zugegriffen werden. Es hat auch noch den Vorteil der Plattformunabhängigkeit und man kann es zur Not auf ner uralten Kiste laufen lassen da es nicht unbedingt den dicken Rechner braucht.

[Generalissimo]

Zitat von Bernhard Geyer:

Sind Aspekte wie Transaktionen, Verteilung auf mehrere Standorte, 24 Stunden-Verfügbarkeit mit Online-Backup nötig, so mußt du eine "richtige" SQL-Datenbank wie Oracle, MS-SQL, MySQL, ... verwenden.

Diese 3 Datenbanken parallel zu nennen finde ich nicht so passend. MySQL ist die ideale Online-DB. Super schnell. Für mittlere bis große Three-Tier-Applications würde ich MS-SQL empfehlen. Vorallem was ich von dem neuen Server gelesen hab und in Verbindung mit .NET (ADO.Net) sind viele interessante Sachen zu machen. Bezüglich Oracle kann ich nur auf Robert_G verweisen. Er sagt es am besten.

[Phoenix]

Zitat von Robert_G:

Ich komme mir selbst nach einem Monat mit Caché noch vor wie ein DB-Newbie.
Zum Bleistift: Tabellen sind Collections persistenter Klassen, die u.A. auch Mehrfachvererbung unterstützen.

Ich glaube das Problem hat jeder, der Relationale Datenbanken gewöhnt ist und dann auf Objektorientierte DB's umsteigt.
Eine Tabelle (als Objekt) als Attribut einer anderen Tabelle einzusetzen ist einfach nicht jedermann's Sache

[Phoenix]

Zitat von Bernhard Geyer:

Sind Aspekte wie Transaktionen, Verteilung auf mehrere Standorte, 24 Stunden-Verfügbarkeit mit Online-Backup nötig, so mußt du eine "richtige" SQL-Datenbank wie Oracle, MS-SQL, MySQL, ... verwenden.

Erm. Nunja, die Transaktions-Unterstützung bei MySQL ist etwas mau (nur auf bestimmten Tabellentypen) und macht die üblichen Geschwindigkeitvorteile von MySQL gegenüber anderen DB's wieder zunichte.

PostgreSQL wird auch gerne Vergessen, ist allerdings auch ein Objektorientierter Ansatz.

[Bernhard Geyer]

Zitat von Generalissimo:

Diese 3 Datenbanken parallel zu nennen finde ich nicht so passend. MySQL ist die ideale Online-DB. Super schnell. Für mittlere bis große Three-Tier-Applications würde ich MS-SQL empfehlen. Vorallem was ich von dem neuen Server gelesen hab und in Verbindung mit .NET (ADO.Net) sind viele interessante Sachen zu machen. Bezüglich Oracle kann ich nur auf Robert_G verweisen. Er sagt es am besten.

Solange eine neue Version noch nicht vorhanden ist, würde (SQL-Server 200x) würde ich gar nichts darauf aufbauen. M$ hat schon oft irgendein Super-Tolles-Kann-Alles-Und-Ist-Besser-Als-Alle-Anderen-Produkt versprochen und die Auslieferung hat sich dann stark verzögert und wurde dann doch nicht mit allen Features ausgeliefert.

Auch hat der M$-Server m.E. eine sehr große Schwäche (und wird sie auch mit der neuen Version vermutlich noch haben): Er unterstützt das Multi-Versions-Konzept nicht!
Dies führt zu einer bei weiten höheren Wahrscheinlichkeit des Auftretens von Timeouts, wenn Änderungen in einer lang andauernden Transaktion durchgeführt werden und jemand anderes lesend auf die Daten zugreifen will.
Oracle, MySQL, Interbase (und andere) liefern gültige Daten zurück, die vor dem Start der Transaktion gütlig waren. M$-SQL-Server hält den Lese-Task an (maximal bis zur Timeout-Zeit) bis die Transaktion beendet ist.

Zitat von Phoenix:

Erm. Nunja, die Transaktions-Unterstützung bei MySQL ist etwas mau (nur auf bestimmten Tabellentypen) und macht die üblichen Geschwindigkeitvorteile von MySQL gegenüber anderen DB's wieder zunichte.

Da ja die Transaktionstabellen-Unterstützung ab MySQL 4 standardmäßig dabei ist, sehe ich das nicht als Nachteil.

[Robert_G]

Zitat von Phoenix:

PostgreSQL wird auch gerne Vergessen, ist allerdings auch ein Objektorientierter Ansatz.

Zu meiner Verteidigung muss ich sagen, dass ich sie schon ein paar Mal empfohlen habe. PostGreSQL besitzt zwar auch wie Caché eine sehr gute Projektion auf SQL, aber an die unglaubliche Performance von Caché reicht so schnell keine andere DB heran.

Den MS SQL Svr würde ich niemanden empfehlen wollen. Das Problem, das Bernhard erwähnt hat, mag zwar ungeheuer nervig sein doch die wirkliche Schwäche gegenüber seinem Hauptkonkurenten Oracle ist die Kindersprache TSQL.
Im SL Svr ist ALLES TSQL, es gibt keine wirklich parallele Engine im gleichen Prozess (wie in Ora für PL/SQL o. Java), deshalb kann man in TSQL nicht programmieren wie in einer Hostanwendung (zum Bsp als ob man mit Delphi auf die DB zugreift).
Auch ist der Sprachumfang von TSQL ziemlich kümmerlich (Das gilt natürlich auch für das PSQL in IB/FB).
Die letzten 2 Punkte wird MS aber mit der Integration von CLR Code in YUKON aus der Welt schaffen. Wenn die DB dann wirklich die CLR-Klassen, wie angekündigt, "versteht" wäre YUKON auch für mich interessant.
So wie er jetzt da steht, wirkt der SQL Svr eher wie eine halbfertige Kopie von Oracle 8i (aus den 90'er Jahren!!!) als ein ernstzunehmendes DBMS.

[Alexander]

Ui. Danke. Das muss ich mir noch mal alles in Ruhe durchlesen