Am Fre, 2003-08-08 um 11.16 schrieb Erhard Schwenk:

Zitat von Rolf-Hubert Pobloth :

...

Hallo Liste,

jetzt kommt eine Frage eines unbedarften zukünftigen Nutzers von mysql unter SuSE 8.2 und KDE 3.x

Es liegt mir eine große Datendatei vor, wo die einzelnen Felder mit Kommata getrennt sind. Die Daten sind aber richtige Text-Daten.

Wenn ich jetzt eine mysql-Datenbank anlege und jedes Feld entsprechend beschreibe, wie kann ich dann die Daten aus der Datenbank.TXT in meine jungfräuliche Buchungssaetze Mysql Datenbank einlesen?

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. Es werden hier keine Buchungen in der mysql Datei vorgenommen, sondern die zig-Tausend Buchungen der letzten 5 Jahre "gespiegelt". Wer kennt nicht die Frage: Der Betrag war xxx.xxDM und ich glaube es war das Dingsbums von Ersatzteil im Jahre 98 oder doch 99??? Eine abgeschlossene Buchhaltung kann diese Frage in den meisten Fällen nicht mehr beantworten. Die Konten sind gedruckt und die Daten werden dann gelöscht. Wenn aber alle Bewegungsdaten in einer mysql Datei eingestellt werden, dann kann man die gesuchten Daten rausfiltern. Haben wir in grauer Vorzeit bereits mit der Nixdorf 8870 und Sorbas gemacht. Geht hervorragend. Verblüffte bereits 1976 die WPs GFs und die Abteilungsleiter. Die EDV hatte immer ein besseres Gedächtnis ;-)))))))

...

Wie ist in diesem Falle der Konsolenbefehl?

Sollte im Handbuch zu finden sein. RTFM. Auf www.mysql.com steht es.

Stimmt, da sind ein paar Beispiele. Werde diese entprechend ausprobieren.

...

Kann mir aus der Liste der Spezialisten mir diesen per PM aufgeben?

Handbuch vorlesen kostet 120 Euro die Stunde.

Tut mir leid, es geht mir wie dem Beethoven, leider fürchterlich taub.

-- Erhard Schwenk

Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx.net Webhosting - http://webhosting.k-itx.net -- Rolf-Hubert Pobloth

Zitat von "M. Bader" :

...

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

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" :

...

...

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