OT Eine Frage an die mysql Spezialisten
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? Wie ist in diesem Falle der Konsolenbefehl? Kann mir aus der Liste der Spezialisten mir diesen per PM aufgeben? Mit einem herzlichen Dank schon mal im voraus -- Rolf-Hubert Pobloth <rhp-berlin@surfnett.de>
-----Original Message----- From: Rolf-Hubert Pobloth [mailto:rhp-berlin@surfnett.de] Sent: Friday, August 08, 2003 10:48 AM To: suse-linux@suse.com Subject: OT Eine Frage an die mysql Spezialisten
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?
Wie ist in diesem Falle der Konsolenbefehl? Kann mir aus der Liste der Spezialisten mir diesen per PM aufgeben?
Hallo, naja, die Form stimmt nicht ganz. kann man aber mit nem guten editor in diese Form bringen :) Um ein Dump einzuspielen müsste es z.B. folgendermassen vorliegen: - INSERT INTO ETERMINE VALUES ('1079',1,'2003-07-21',2003,30); INSERT INTO ETERMINE VALUES ('1103',1,'2003-07-24',2003,30); INSERT INTO ETERMINE VALUES ('1076',1,'2003-07-23',2003,30); INSERT INTO ETERMINE VALUES ('1176',1,'2003-07-22',2003,30); INSERT INTO ETERMINE VALUES ('1042',1,'2003-07-24',2003,30); INSERT INTO ETERMINE VALUES ('1136',1,'2003-07-22',2003,30); INSERT INTO ETERMINE VALUES ('1037',1,'2003-07-24',2003,30); - ein dump kannst du dann mit mysql connect <db>; source /pfad/zum/dump.dmp -- MfG Yann Wissenbach - Administration/Support compass Gesellschaft fuer Medientechnologie mbH Robert-Koch-Str. 35 D-55129 Mainz mail: y.wissenbach@compass-online.de www : http://www.compass-online.de fon : +49 6131 90 63 - 121 fax : +49 6131 90 63 - 222
Hallo Rolf-Hubert, * Rolf-Hubert schrieb am 08.08.2003:
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?
Wie ist in diesem Falle der Konsolenbefehl?
Schau Dir mysqlimport an. ... Usage: mysqlimport [OPTIONS] database textfile... ...
Kann mir aus der Liste der Spezialisten mir diesen per PM aufgeben?
Grüße, Tom
Zitat von Rolf-Hubert Pobloth <rhp-berlin@surfnett.de>:
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.
Wie ist in diesem Falle der Konsolenbefehl?
Sollte im Handbuch zu finden sein. RTFM. Auf www.mysql.com steht es.
Kann mir aus der Liste der Spezialisten mir diesen per PM aufgeben?
Handbuch vorlesen kostet 120 Euro die Stunde. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx.net Webhosting - http://webhosting.k-itx.net
Am Fre, 2003-08-08 um 11.16 schrieb Erhard Schwenk:
Zitat von Rolf-Hubert Pobloth <rhp-berlin@surfnett.de>:
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 <rhp-berlin@surfnett.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.
Hallo, hmm, und warum gibt`s diese Tools? Weil eine "vernünfige Konsistensprüfung" immer Aufgabe des Benutzers/ Programms ist. Man kann diese Probleme natürlich mit Hilfe von Normalisierung und gründlich durchdachten Indizes wesentlich vereinfachen. Aber letztlich ist immer ein die DB "betreuendes System" dafür verantwortlich. Ergo ist das weniger die Unfähigkeit von mysql, .... ;-) zurück zum Thema: falls Du irgendwo einen Web-Account mit php hast, kann ich phpmyadmin empfehlen. schnell und einfach zu bedienen. Mfg Maik
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
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
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
Hallo,
From: Erhard Schwenk [mailto:eschwenk@fto.de] Sent: Friday, August 08, 2003 2:41 PM
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.
Jau, natürlich richtig. War an dem Tag wohl irgendwie neben mir. Bischen stressig hier. :) Grüße aus der Sonne Maik
Am Freitag, 8. August 2003 10:47 schrieb Rolf-Hubert Pobloth:
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?
also, "PHPmyAdmin" hat ein gutes Front End fuer den Import von CVS Dateien. Alternativ gibt es den consolen Befehl "mysqlimport", der gut "--help" Dokumentiert ist. Beide importieren CVS Dateien ohne grosse Probleme. cu stonki -- www.stonki.de: the more I see, the more I know....... www.proftpd.de: Deutsche ProFTPD Dokumentation www.krename.net: Der Batch Renamer für KDE www.kbarcode.net: Die Barcode Solution für KDE
participants (7)
-
Erhard Schwenk -
Jan.Trippler＠t-online.de -
M. Bader -
Rolf-Hubert Pobloth -
Stefan Onken -
Thomas Preissler -
Yann Wissenbach