Zitat von "M. Bader" <newsletter@one-mb.de>:
From: Rolf-Hubert Pobloth [mailto:rhp-berlin@surfnett.de] Sent: Friday, August 08, 2003 11:52 AM Am Fre, 2003-08-08 um 11.16 schrieb Erhard Schwenk:
Mal abgesehen davon, daß mysql für Buchungssätze mangels wirklich funktionierender Konsistenzsicherung definitiv das falsche Werkzeug ist, gibts dafür mehrere Varianten von Tools.
Im Prinzip richtig, aber in diesem Falle falsch.
hmm, und warum gibt`s diese Tools? Weil eine "vernünfige Konsistensprüfung" immer Aufgabe des Benutzers/ Programms ist.
Nein. Konsistenzsicherung (nicht prüfung!) ist eine Kernaufgabe eines RDBMS. Man benutzt dazu Transaktionen und Constraints. Nur damit kann man sicherstellen, daß die Datenbank im Crash-Fall auch in einem konsistenten Zustand bleibt. Anwendungsseitig ist dies gar nicht sicher möglich. Eben deshalb will man für Buchhaltungsdaten, bei denen Konsistenz nunmal das A und O ist, nicht mysql verwenden, sondern z.B. PostgreSQL, Oracle, Informix, DB/2 oder auch Adabas. Eben ein ausgereiftes RDBMS, das eine saubere Crash-Recovery garantieren kann. MySQL kann dies nur bedingt. Natürlich wird das Ganze im "Normalbetrieb" trotzdem erstmal so aussehen, als ob es funktioniert. Wenn man das Problem bemerkt, wird es bereits zu spät sein.
Man kann diese Probleme natürlich mit Hilfe von Normalisierung und gründlich durchdachten Indizes wesentlich vereinfachen.
Nein. Normalisierung dient nicht der Konsistenzsicherung, sondern der Vermeidung von Redundanzen. Indizies haben mit Konsistenzsicherung auch fast nichts zu tun, sie dienen in Erster Linie der Zugriffsoptimierung. Lediglich die Eindeutigkeit von Schlüsseln kann über Indices sichergestellt werden, aber das auch nur sehr begrenzt. Zu einer ordentlichen Konsistenzsicherung gehört deutlich mehr, z.B.: - Vollständige Transaktionskontrolle als Voraussetzung für eine sichere Crash-Recovery in einen definierten Zustand (die allerdings so, wie mysql Transaktionen umsetzt, prinzipbedingt im Crashfall nicht zu 100% garantiert werden kann - das verhindert schon der transparente Cache des Filesystems). - Vollständige Definition der Kriterien zur referentiellen Integrität zwischen Tabellen - Sicherstellung von RI und weiteren Konsistenzkriterien durch Einbau von Triggern und Constraints - Üblich ist außerdem eine Regelmäßige Sicherung/Spiegelung der Transaction Logs als inkrementelles Backup. Bringt aber nur was, wenn man diese dann ggf. auch nachfahren kann.
Aber letztlich ist immer ein die DB "betreuendes System" dafür verantwortlich.
Per Definition ist genau das RDBMS dafür verantwortlich. Eben deshalb benutzt man eines. Wäre die Applikation dafür verantwortlich, könnte man die Daten gleich in Random Access Files abspeichern, das wäre performanter und mit weniger Ballast verbunden.
Ergo ist das weniger die Unfähigkeit von mysql, .... ;-)
Ergo ist mysql nicht wirklich ein RDBMS, sondern mehr eine Dateiverwaltung mit aufgesetztem SQL-Parser. Und nicht mal der ist vollständig. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx.net Webhosting - http://webhosting.k-itx.net