Hallo,
eine Frage zu naechtlicher Stunde: ich habe mich gerade mit mySQL herumgeschlagen:
UPDATE konten INNER JOIN buchungen ON konten.ktoID = buchungen.buKonto SET konten.ktoSaldo = konten.ktoSaldo + buchungen.buBetrag;
und dann nach einer google-Suche (UPDATE INNER JOIN) in der deutschen Newsgroup festgestellt, dass mein mySQL das gar nicht kann. Es gab aber einen Hinweis auf mySQL 4.0x (das soll UPDATE mit INNER JOIN koennen). Meine Frage: hat das schon jemand unter Linux im Einsatz und wenn ja: wie stabil ist es und welche Version ist fuer ein SuSE 7.3 zu empfehlen? Kann man das rpm verwenden?
vielen Dank, Stefan
.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 04 September 2002 00:55, Stefan Lagotzki wrote:
eine Frage zu naechtlicher Stunde: ich habe mich gerade mit mySQL herumgeschlagen:
Muss es unbedingt mySQL sein? Mit Postgres kann man ganz prima Transaktionen machen und kann sowas auch in mehrere Kommandos aufloesen ohne die Integritaet zu verlieren. Gerade fuer Transaktionskandidaten wie Kontenverwaltung ist mySQL denkbar ungeeignet.
Konrad
- -- "The Computer made me do it."
Konrad Rosenbaum wrote:
Muss es unbedingt mySQL sein? Mit Postgres kann man ganz prima Transaktionen machen und kann sowas auch in mehrere Kommandos aufloesen ohne die Integritaet zu verlieren. Gerade fuer Transaktionskandidaten wie Kontenverwaltung ist mySQL denkbar ungeeignet.
Hallo Konrad,
es war nur ein Uebungsbeispiel. Mir war klar, dass es IRL anders gemacht wird. Aber wenn es nur die Kontenverwaltung auf einem Rechner mit einem User waere, dann wuerde es funktionieren(??). Beispiele: eingehende und ausgehende Zahlungen, Haushalt etc.
Was kann noch schief gehen, wenn nur ein User auf die Datenbank zugreift? Die Tabelle der aktuellen Buchungen wird im naechsten Schritt an die Tabelle der gespeicherten Buchungen angefuegt und danach sofort geleert. Neue Buchungen werden aus einer externen Datei eingelesen. Somit ist gewaehrleistet, dass jede Buchung nur genau einmal stattfindet.
Ich habe frueher aehnliche SQL-Aufgaben mit FEM-Berechnungsdaten loesen muessen (auch im Single-User-Modus) und da hat das selbe Prinzip eigentlich immer funktioniert.
Ich habe inzwischen mySQL 4.03 mal auf einen nicht-produktiven Rechner mit ebensolchem Betriebssystem getestet und da hat die selbe Abfrage dann funktioniert.
Aber Postgres wollte ich mir sowieso schon lange mal ansehen.
viele Gruesse Stefan
.
On Wednesday 04 September 2002 10:16, Stefan Lagotzki wrote:
es war nur ein Uebungsbeispiel. Mir war klar, dass es IRL anders gemacht wird. Aber wenn es nur die Kontenverwaltung auf einem Rechner mit einem User waere, dann wuerde es funktionieren(??).
Transaktionen decken den (seltenen) Fall ab, daß inmitten einer solchen Abfrage z.B. der Strom ausfällt oder eine sonstige Unterbrechung geschieht. Egal, ob nun zuerst in A geschrieben und dann in B gelöscht wird, oder umgekehrt, es kommt immer zu Inkonistenzen (fehlende bzw. doppelte Einträge). Das ist sogar fast 1:1 mit Journaling Dateisystemen zu vergleichen: Auch dort wird ein Log geführt, welches im Bedarfsfall dazu dient, einen Urzustand wieder herzustellen.
In MySQL gibt es auch Transaktionen, allerdings werden die erst ab Version 4 standardmäßig mit dabei sein, und die sollte man für wichtige Daten noch nicht einsetzen.
Aber Postgres wollte ich mir sowieso schon lange mal ansehen.
Solltest du. Heut Mittag wurde 7.3beta fertig gestellt und wird morgen oder übermorgen sicher zum Download bereitstehen. Dort ist endlich ein DROP COLUMN mit drin, und auch CREATE TABLE xxx WITH OWNER yyy, was für mich eigentlich noch die letzten Kritikpunkte waren.
Praxisbeispiel: Ich habe für Kommilitonen während der Prüfungszeit eine Postgres-Datenbank bereitgestellt, damit sie sich nicht mit dieser abartigen Sybase-DB quälen mußten (und MySQL hat nur etwa 70% der Beispiele beherrscht). Nun konnte ich zwar Rechte vergeben, aber ein GRANT CREATE gab es noch nicht, so daß jeder dort unendlich viele Tabellen hätte erstellen können, wo er wiederum volle Schreibrechte drin gehabt hätte.
Josef
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 04 September 2002 19:10, Josef Spillner wrote:
On Wednesday 04 September 2002 10:16, Stefan Lagotzki wrote:
es war nur ein Uebungsbeispiel. Mir war klar, dass es IRL anders gemacht wird. Aber wenn es nur die Kontenverwaltung auf einem Rechner mit einem User waere, dann wuerde es funktionieren(??).
Transaktionen decken den (seltenen) Fall ab, daß inmitten einer solchen Abfrage z.B. der Strom ausfällt oder eine sonstige Unterbrechung geschieht. Egal, ob nun zuerst in A geschrieben und dann in B gelöscht wird, oder umgekehrt, es kommt immer zu Inkonistenzen (fehlende bzw. doppelte Einträge). Das ist sogar fast 1:1 mit Journaling Dateisystemen zu vergleichen: Auch dort wird ein Log geführt, welches im Bedarfsfall dazu dient, einen Urzustand wieder herzustellen.
Erzaehl das nicht deinem DB-Prof. der wird Dich dafuer durchfallen lassen!
Fuer dieses Feature ist das Transaction-Log zustaendig (WAL bei PgSQL).
Transaktionen sind dazu da Nutzer/Prozesse voneinander zu isolieren, also zu verhindern, dass unterschiedliche Prozesse widerspruechliche Daten erzeugen. Es gibt da ein ganzes Buendel von Szenarien:
Lost-write: A/B lesen A/B rechnen A schreibt B schreibt (ueberschreibt das Ergebnis von A)
inconsistent write A liest B liest B schreibt A schreibt Ergebnisse, die auf Grundlage veralteter Daten erstellt wurden
usw.
http://openacs.org/philosophy/why-not-mysql.html zitiert das ACID Prinzip, der Rest ist Flame...
In MySQL gibt es auch Transaktionen, allerdings werden die erst ab Version 4 standardmäßig mit dabei sein, und die sollte man für wichtige Daten noch nicht einsetzen.
Wahrscheinlich irre ich mich: MySQL macht Transaktionen ohne Rollback, das ist keine sehr gute Idee...
Ausserdem gilt diese Implementation noch als recht wacklig.
Konrad
- -- Never shown Star Trek episodes #25: Janeway: "Ok, now. What do you want on the bridge young man?" Pizzaboy: "Who of you ordered this pizza?" Paris: "Ooops."
On Wednesday 04 September 2002 20:31, Konrad Rosenbaum wrote:
Erzaehl das nicht deinem DB-Prof. der wird Dich dafuer durchfallen lassen!
Er wird im Moment mit anderen Dingen beschäftigt sein. Vor ein paar Tagen hat er vermutlich versehentlich das falsche CVSROOT angegeben, jedenfalls hat lists.kde.org jetzt eine schöne Liste an Dateien, die nicht importiert werden konnten, und das sah verdammt nach irgendeinem SQL-Projekt aus. http://lists.kde.org/?l=kde-cvs&m=103035818404710&w=2
Fuer dieses Feature ist das Transaction-Log zustaendig (WAL bei PgSQL).
Es gab auf der Users-Mailingliste dort einen, der erst löschte und dann fragte wozu diese Datei gut ist :)
Transaktionen sind dazu da Nutzer/Prozesse voneinander zu isolieren, also zu verhindern, dass unterschiedliche Prozesse widerspruechliche Daten erzeugen. Es gibt da ein ganzes Buendel von Szenarien:
Dafür ist unter anderem MVCC da, was von Oracle (?) abstammt. Jedenfalls geht es darum, die Daten konsistent zu halten, und wenn nach einem Stromausfall aus einer 1 eine 0 wird, verstößt das auch gegen das ACID-Prinzip.
Datenbank-basierte Dateisysteme gibt es auch noch...
Josef
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 04 September 2002 21:31, Josef Spillner wrote:
On Wednesday 04 September 2002 20:31, Konrad Rosenbaum wrote:
Transaktionen sind dazu da Nutzer/Prozesse voneinander zu isolieren, also zu verhindern, dass unterschiedliche Prozesse widerspruechliche Daten erzeugen. Es gibt da ein ganzes Buendel von Szenarien:
Dafür ist unter anderem MVCC da, was von Oracle (?) abstammt.
MultiVersion Concurrency Control ist eine optimierte Implementation von Transaktionen. Hier ist es moeglich, dass mehrere Prozesse auf den selben Datensaetzen arbeiten und dabei unterschiedliche Versionen sehen. Allerdings darf nur einer davon schreiben, sonst geht die Konsistenz verloren. Beispiel:
A liest (sieht Version 18 von SELECT meinespalte FROM meintab) B liest (sieht auch Version 18 ...) C liest (sieht auch Version 18 ...) B schreibt (und erzeugt damit Version 19) B ist fertig A/C lesen weiter (sehen immernoch 18) C versucht zu schreiben (18 ist aelter als 19, Rollback [je nach Implementation koennte ein Restart kommen]) A ist fertig (kein Problem, 18 war in sich konsistent, der naechste Aufruf von A wird 19 zeigen)
Jedenfalls geht es darum, die Daten konsistent zu halten, und wenn nach einem Stromausfall aus einer 1 eine 0 wird, verstößt das auch gegen das ACID-Prinzip.
Um genau zu sein gegen C (Consistency).
Datenbank-basierte Dateisysteme gibt es auch noch...
Bitte kein Oracle Marketing!
DB-basierte Dateisysteme sind so ziemlich der groesste Schwachsinn, den die erfunden haben (neben dem Marketinggag mit dem "i" in der Version): fuer ein FS gibt es keine Moeglichkeit Anfang und Ende einer Transaktion anzuzeigen, ausser Locks und die kann man viel besser mit einem normalen FS abbilden.
Wie der von mir zitierte Artikel schon sagt: - --------- If what you want is raw, fast storage, use a filesystem. If you want to share it among multiple boxes, use NFS. If you want simple reliability against simplistic failure, use mirroring. Want a SQL interface to it all? Use MySQL.
Now, if what you want is data storage that guarantees a certain number of invariants in your data set, that allows for complex operations on this data without ever violating those constraints, that isolates simultaneous users from each other's partial work, and that recovers smoothly from just about any kind of failure, then get your self a real RDBMS. - ----------
Konrad
- -- Never shown Star Trek episodes #20: Riker: "Mr. Worf, do you see that?" Worf: "No, Sir." Riker: "Perhaps if you open your eyes now?"
On Wed, 04 Sep 2002 23:01:06 +0200, Konrad Rosenbaum wrote:
Jedenfalls geht es darum, die Daten konsistent zu halten, und wenn nach einem Stromausfall aus einer 1 eine 0 wird, verstößt das auch gegen das ACID-Prinzip.
Um genau zu sein gegen C (Consistency).
Nicht zwingend. Wenn in der Mitarbeitertabelle, Spalte Name aus "Rosenbaum" ein "Rosentraum" wird, hat das auf C höchstwahrscheinlich keine Einfluß. Dieser Fall fällt unter D, der in etwa besagt, daß alle Daten nach Abschluß der Transe :) so bleiben wie sie sind, außer sie werden von einer anderen Transe erneut manipuliert.
Datenbank-basierte Dateisysteme gibt es auch noch...
Bitte kein Oracle Marketing!
DB-basierte Dateisysteme sind so ziemlich der groesste Schwachsinn,
Letzlich sind alle Dateisysteme DB-basiert. Man darf sich nur keine gar zu enge Definition von DB hernehmen.
den die erfunden haben (neben dem Marketinggag mit dem "i" in der Version): fuer ein FS gibt es keine Moeglichkeit Anfang und Ende einer Transaktion anzuzeigen, ausser Locks und die kann man viel besser mit einem normalen FS abbilden.
Genauso wie locks könnte man einen Transaktionsmechanismus für Filesysteme standardisieren. Bei locks muß sich sich der Programmierer um alles selbst einen Kopf machen. Dead locks und eventuell trotz lock mögliche Parallelität wären 2 Themen. Locks sind nur ein primitives Werkzeug, um transaktions- ähnliche Absicherungen zwischen Programmen/Threads zu bauen.
Programmierung mit locks macht viel Arbeit, bietet Fehlermöglichkeiten and kostet Zeit. Man _kann_ mit locks die effektiveren Programme schreiben, da man als Programmierer genau weiß, was passieren kann. Man muß dabei dummerweise für jedes Programm die locks neu optimieren. In der Praxis passiert sowas selten. Da wird eben das ganze File gelockt und basta. Mit expliziten Transaktionen kommt man zwar nicht an die Effizienz aufwändig optimierter Locks ran, bekommt aber mit minimalem Aufwand erstmal sein Programm korrekt zum Laufen. Transaktionen sind wirklich eine extrem hilfreiche Spielerei. Bleibt die Frage, wo man die Transaktions- unterstüztzungen einbaut: Am besten natürlich weit unten und darauf aufbauend in jeder Schicht. Das wurde allerdings verpennt. Datenbanken wie Oracle arbeiten deshalb direkt auf Blockgeräten und basteln sich darauf einen eigenen Transaktionsmechanismus für den Platten-IO. Wenn es Filesystem mit Transaktioen überall gäbe, hätten sie darauf aufsetzten können.
Übrigens: Bei neueren Entwicklungen (Java2EE) kannst du nicht nur FS- und DB-Zugriffe in Transaktionen stecken sondern den ganzen Programmablauf - also auch Methodenaufrufe. Du kannst solchen transaktional ablaufenden Code auch noch in Transaktionen beliebig schachteln. Wenn du das per Hand mit locks realisieren willst, brauchst du Jahre. Einem Low-Level-Hacker mag das idiotisch vorkommen. Die Praxis zeigt aber, das solche Mechanismen gern angenommen weden, weil sie eben in kurzer Zeit zu korrekten Anwendungen führen. DARAUF kommt es an. Effizienz innnerhalb der Anwendung interessiert oft keine Sau. Da wird nur soweit optimiert, daß das Programm gerade so ausreichend schnell ist. Die Anwendung vertrödelt sowieso die meiste Zeit mit Warten auf die DB.
BTW: locks vs. Transaktionen ist die gleiche Diskussion wie Assembler vs. C. Klar _kann_ man mit Assembler die besseren Programme schreiben. Trotzdem entsteht viel mehr Software in C, weil die Vorteile von C den Effizienznachteil in 9x% der Fälle überkompensieren.
Reinhard
lug-dd@mailman.schlittermann.de
-
Josef Spillner -
Konrad Rosenbaum -
Reinhard Foerster -
Stefan Lagotzki