Auch wenn es mit dem eigentlichen Thread-Thema nicht mehr so viel zu tun hat ... On Fre, 08 Aug 2003 at 14:40 (+0200), Erhard Schwenk wrote: [Erhard, kannst du Deine Zeilen mal kürzer machen - das liest sich auf der Konsole besch...]
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.
Im Prinzip ACK, aber eine kleine Anmerkung: Konsistenz-Sicherung dient nicht vorrangig dem Recovery, sondern der Abbildung betriebswirtschaftlicher Anforderungen. Beliebtes Beispiel für Transaktionen: Umbuchung eines Betrags von einem Konto auf ein anderes - erst wenn _beide_ Buchungen erfolgreich gelaufen sind, darf die Transaktion abgeschlossen werden - wenn eine der beiden DB-Aktionen schiefgeht, darf von _keiner_ der Buchungen was übrigbleiben. Fehler treten in den seltensten Fällen dadurch auf, dass es einen Crash gibt (dann tritt, wie schon richtig bemerkt das Recovery-Verfahren einer *richtigen* DB in Aktion), viel häufiger sind Fälle, dass z. B. das Zielkonto während der Transaktion von einem anderen Prozess bebucht wird und damit gesperrt ist - wie soll die Anwendung das wissen? Oder der Anwender? Was passiert, wenn ein anderer Anwender zur gleichen Zeit ebenfalls vom Quellkonto abbucht und das Konto plötzlich nicht mehr gedeckt ist? Sowas kann nur die DB-Engine wissen und abfangen. Sowas kann man in einer Multiuser-Umgebung der Anwendung oder dem Anwender nicht überlassen. Mal ganz davon abgesehen, dass in Batch-Programmen, wie sie in Banken häufig eingesetzt werden, man ja wohl schlecht einen Sachbearbeiter fragen kann, welche der konkurrierenden Buchungen nun die richtige sei. Beispiel zur Datenkonsistenz: In einer Warenwirtschaft darf ein Artikel-Stammsatz erst dann gelöscht werden, wenn keine offenen Aufträge mehr für ihn vorliegen. Soll da ein Anwender erst nachgucken? Nein, sowas löst man über referentielle Integrität der Artikelnummer im Stammsatz zur Auftragspositionstabelle. Dann verhindert das RDBMS zuverlässig, dass ein solches Löschen erfolgreich ist (und kann auch nicht durch einen *pfiffigen* Anwender, der SQL kann, ausgehebelt werden ;)
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.
Das macht man über die Definition eines *primary key* (was IIRC auch MySQL beherrscht) - dann sorgt die DB schon für einen entspr. Index.
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).
Siehe oben - Crash-Recovery ist nur eine (und IMHO nicht die wichtigste) Aufgabe der Transaktionskontrolle. Ein professionelles DBMS wird anhand der Transaktionslogs feststellen können, welche Transaktionen erfolgreich durchlaufen wurden und welche nicht - und sie dann entweder nachziehen oder zurückrollen.
- 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.
Unter Informix gibt es z. B. die Möglichkeit, die Logs sofort wenn sie voll sind zu sichern. Damit kann man den DB-Zustand bei einem Crash auf einen Stand zeitnah zum Ausfall wiederherstellen - wichtig bei Datenbanken mit hohem Transaktionsaufkommen.
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.
ACK. Übrigens nicht nur per Definition: Alles, was man innerhalb der DB erledigen kann, ist a) schneller (weil z. B. Procedures schon precompiliert vorliegen) b) sicherer, weil die DB-Engine die Kontrolle darüber behält c) sauberer, weil mehr einheitliche (im Sinne: für alle Anwendungen) Schnittstellen zur Verfügung stehen d) eleganter, weil man der Anwendung mehr Arbeit abnimmt (im Sinne einer sauberen Trennung von Programmlogik und Präsentation) e) einfacher, weil nicht jede Anwendung die Programmlogik neu implementieren muss. Also sollte man die Fähigkeiten von DBMS auch ausnutzen - man erspart sich viel Arbeit.
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.
ACK Jan