Am Freitag, 8. August 2003 14:40 schrieben Sie:
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.
Hallo liebe,nette und hilfreiche Listenmitglieder, es geht doch nicht darum mit mysql eine Buchhaltung aufzubauen. In diesem Falle gebe ich den Vorredner vollkommen recht, daß es nach den GOB so nicht zu machen ist. Die Datenbank, also meine Quelle, ist eine IBM-Datenbank mit allen entsprechenden Vorrichtungen. Halt eine teures Industrieprodukt. Es ging mir doch nur darum, die Bewegungsdaten, die als Datensätze im Textformat, kommasepariert, als Ausdruck vorliegen, in eine mysql-Datei einzulesen um dann vom Netz aus auf diesen Informations-Datenbestand, zugreifen zu können. Also, nix mit buchen, schreiben usw. NUR LESEN. Die mysql-Datei wird dann monatlich, beim Monatsabschluß, mit den neuen Daten im append-modus erweitert. Bereinigt um die persönlichen Daten, die der übrigen Mannschaft nichts angehen, z.B. Gehalts- und Lohndaten, Reisekosten der GFs usw. Das für die mysql Datei eine entsprechende Satzbeschreibung erstellt werden muß, ist Voraussetzung für die sachgerechte Übernahme der Daten. Mir ging es nur um den Consolenbefehl um aus einer DATEI.TXT diese Datensätze in die Datenbank zu schreiben und daß dann immer Konto auf Konto geschrieben wird. Vielleicht hat ja jemand den kleinen Script auf seinem Rechner liegen und stellt mir diesen schnell mal freundlich zur Verfügung. Mit einem sonnigen Gruß aus Berlin Rolf-Hubert