Jan Trippler wrote:
[1] Es kann keine DB geben, aus der nur gelesen wird - irgendwann müssen die Daten mal reinkommen. Mit Ausnahme von reinen Archiv-DB's (ohne Aktualisierung) wird jede DB mehr oder regelmäßig verändert. Fehlende referentielle Integrität beschert also mindestens der Aktualisierungs-SW zusätzliche Arbeit (es sei denn, die Prüfung der Konsistenz wird bereits vorher - in einer anderen OLTP-DB z. B. - erledigt). Ich hatte mit nur lesen auch nur daran gedacht, daß z.B. Apache größtenteils nur lesend zugreift und normalerweise selten komplexe UPDATEs oder INSERTs über x Tabellen gemacht werden.
[2] Der Knackpunkt in Bezug auf Transaktionen steht in meiner anderen Mail. Ja und, habe ich was anderes behauptet?
[3] Stored Procedures haben nichts mit Aktualisierungen der DB zu tun. Sie sind genauso nützlich beim Lesen von Daten, da SQL keinerlei Mittel für Programmablaufsteuerung mitbringt (if - then, do - while, for - next, ...). Du meinst wahrscheinlich Trigger - dies sind ereignisgesteuerte Prozeduren (INSERT, UPDATE, DELETE). Nö, ich weiß genau, von was ich schreibe. Waren ja auch nur als Beispiele gedacht, was MySQL fehlt. <Zitat:> ...., brauche ich auch keine Transaktionen, StoredProcedures, referentielle Integrität und all das, was in MySQL fehlt. ^^^^^^^^^^^^^^^^^ </Zitat>
Es gibt schon einige Features, die mir für komplexere DB-Anwendungen fehlen würden, für die Mehrzahl der DB-Anwendungen im Int[er/ra]net reicht mySQL aber aus. Wenn es um ausgewachsene kaufmännische Anwendungen geht, würde ich derzeit immer auf andere DBMS zurückgreifen (unter Linux: Informix, Oracle, Interbase, Adabas, ...). ACK, deswegen benutze ich auch nicht MySQL für sowas.
mfG Wolfgang Wagner --------------------------------------------------- Wolfgang.Wagner@allgaeu.org --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com