Re: Datenbank entscheidung?!?!

[Dirk Munzinger <d_munzinger_(at)_sem-gmbh.com>]

Moin,

> > Wir haben sind dabei ein riesieges projet zu starten.
> > nun meine frage was ist für uns die beddere db?
> > MySQL oder ORACLE???
> >
> Naja das kommt drauf an. Eventuell sogar beides.
> 
> Vorteile:
> Ora: viele Features, gut recoverbar
> Mysql: schnell wie sau, kostenlos
> 
> Nachteile:
> Ora: langsamer als MySQL, teuer, DB-Administrator notwendig.
> Mysql: Bedingt recoverbar, es fehlen einige Dinge im SQL-Umfeld.

Also ich frage mich, ob die Diskussion wirklich den Kern trifft. Das
Hauptproblem, das ich immer wieder sehe ist das Datenbank-Design selbst.
Was da oft rauskommt ist alles andere als ...
Mit einem schlechten Design kannst mensch jede noch so schnelle DB zum
Stillstand bringen und die Deadlocks erledigen dann noch den Rest.
Also ich würde hier folgendes Vorgehen vorschlagen:
- Sich selbst Fragen: bin ich in der Lage eine ordentliche DB
aufzusetzen ? Wenn Nein, dann sollte mensch besser mal in den Gelben
Seiten nachschauen :-)
- Wenn JA erst mal das Datenmodel erstellen und auf einer Test-DB
optimieren (egal was für eine System). Hier gehört auch die
Normalisierung und die bewusste NICHTBEACHTUNG der Normalisierung dazu
!!
- weit, weit in die Zukunft blicken; was kann der Anwender noch für
wünsche haben ? Was kann schon vorgesehen werden ?
- mit reichlich Datenmengen testen. Es nützt nichts, zwei Datensätze
anzulegen und sich zu freuen, dass alles schön schnell läuft. Mit
solchen Datenbeständen hat Access auch keine Probleme :-) Wenn dann aber
im laufe der Zeit einiges zusammen kommt, sieht die Sache anders aus.
- Wenn das soweit läuft, kann mensch sich die Frage stellen, auf welcher
Software das System nun läuft; hierzu zähle ich nicht nur das
eigentliche DBMS sonder auch das OS, z.B. Zugriff auf die physikalischen
DB-Files!!

Oracle hat normalerweise den Ruf, auch bei grossen Datenmengen
gleichbleibend schnell zu sein (wenn das Design stimmt) und wird deshalb
in Bereichen eingesetzt, in denen viele Daten anfallen. Sybase ist
meiner Erfahrung nach bis zu einer gewissen Datenmenge schneller als
Oracle aber wenn diese Grenze überschritten wird, wirds problematisch. 
Die Möglichkeiten die diese DBMS (natürlich auch MS-SQL, Interbase DB/2
usw.) implementiert haben (Stored Procs, Triggers etc) sind enorm, was
sich aber auch sehr negativ auswirken kann; z.B. macht jeder
Transactionsmechanismus die DB langsamer, da hier oft eine redundante
Datenhaltung notwendig ist um überhaupt ein Rollback zu ermöglichen.
Triggers sind auch sehr gut geeignet um die Geschwindigkeit zu
reduzieren etc. etc. . 
Also hier mal die Frage stellen, ob mensch dies alles braucht ? Übrigens
unterstützt MySQL auch Transactionen, wenn entsprechend compiliert.

Ich verwende MySQL z.B. sehr gerne wegen der Geschwindigkeit; da kommt
kein anderes System mit auch bei grossen Datenmengen. Als vergleich
hatte ich mit Interbase 4.nochetwas sehr grosse
Geschwindigkeitsprobleme. Oracle vermeide ich normalerweise wegen seiner
Aufgeblähtheit und Sybase kann mir nicht die erwartete Leistung bei
grossen Datenmengen liefern.
Das fehlen von Stored Procs ist zwar Schade, aber mensch kann damit
leben; hierzu gibt es auch Alternativen.
Triggers nerven mich einfach - besonders bei der Optimierung von DBs und
können den Kopfschmerzfaktor schnell ansteigen lassen.
Fazit: im grossen und ganzen bin ich mit MySQL sehr zufrieden und ich
hatte bisher noch keine Anforderung, die damit nicht realisiert werden
konnte. 
Also wieso nicht mal mit MySQL versuchen; wenn's die Anforderungen nicht
erfüllt kann immer noch umgestiegen werden. Vom Datenmodel her muss das
unabhängig sein; bei der Verwendung von Stored Proc. ist aber Vorsicht
geboten.

Tschau, Dirk

---
*** Weitere Infos zur Mailingliste und MySQL unter http://www.4t2.com/mysql