On Die, Apr 18, 2000 at 05:13:39 +0200, Wolfgang Wagner wrote: [schnelles mySQL]

das ist richtig, schnell schon, und solange nur gelesen wird aus der Datenbank, brauche ich auch keine Transaktionen, StoredProcedures, referentielle Integrität und all das, was in MySQL fehlt. Sobald jedoch mehrere (viele) User Daten schreiben und / oder ändern, sind die fehlenden Features ganz hilfreich, weil damit ein Teil der Intelligenz in das Backend verlagert wird und die Frontend-Applikation damit einfacher wird.

[1] Es kann keine DB geben, aus der nur gelesen wird - irgendwann müssen die Daten mal reinkommen. Mit Ausnahme von reinen Archiv-DB's (ohne Aktualisierung) wird jede DB mehr oder regelmäßig verändert. Fehlende referentielle Integrität beschert also mindestens der Aktualisierungs-SW zusätzliche Arbeit (es sei denn, die Prüfung der Konsistenz wird bereits vorher - in einer anderen OLTP-DB z. B. - erledigt). [2] Der Knackpunkt in Bezug auf Transaktionen steht in meiner anderen Mail. [3] Stored Procedures haben nichts mit Aktualisierungen der DB zu tun. Sie sind genauso nützlich beim Lesen von Daten, da SQL keinerlei Mittel für Programmablaufsteuerung mitbringt (if - then, do - while, for - next, ...). Du meinst wahrscheinlich Trigger - dies sind ereignisgesteuerte Prozeduren (INSERT, UPDATE, DELETE). Es gibt schon einige Features, die mir für komplexere DB-Anwendungen fehlen würden, für die Mehrzahl der DB-Anwendungen im Int[er/ra]net reicht mySQL aber aus. Wenn es um ausgewachsene kaufmännische Anwendungen geht, würde ich derzeit immer auf andere DBMS zurückgreifen (unter Linux: Informix, Oracle, Interbase, Adabas, ...). Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On Die, Apr 18, 2000 at 10:32:44 +0200, Wolfgang Wagner wrote:

Jan Trippler wrote:

...

[1] Es kann keine DB geben, aus der nur gelesen wird - irgendwann müssen die Daten mal reinkommen. Mit Ausnahme von reinen Archiv-DB's (ohne Aktualisierung) wird jede DB mehr oder regelmäßig verändert. Fehlende referentielle Integrität beschert also mindestens der Aktualisierungs-SW zusätzliche Arbeit (es sei denn, die Prüfung der Konsistenz wird bereits vorher - in einer anderen OLTP-DB z. B. - erledigt). Ich hatte mit nur lesen auch nur daran gedacht, daß z.B. Apache größtenteils nur lesend zugreift und normalerweise selten komplexe UPDATEs oder INSERTs über x Tabellen gemacht werden.

Zum einen ist die Komplexität von Insert- oder Update-Kommandos völlig uninteressant: Inkonsistenz ist Inkonsistenz, egal ob es 1 oder 500 Tabellen betrifft. Wenn es sich um eine 24x7-DB handelt (das ist bei Web-DB's in der Regel der Fall), dann ist es auch egal, ob Aktualisierungen 1x pro Jahr oder 1x pro Minute passieren - ohne Transaktionssicherung und entsprechende Lock- und Isolationslevel kommt es zu Inkonsistenzen.

...

[2] Der Knackpunkt in Bezug auf Transaktionen steht in meiner anderen Mail.

Ja und, habe ich was anderes behauptet?

Ich wollte mich nur nicht wiederholen; IMHO bedarf es einer etwas differenzierteren Betrachtung der Anforderungen an die DB als nur der Entscheidung *Schreiben mehrere Prozesse gleichzeitig*. Wenn Du also schon fragst: Ja.

...

[3] Stored Procedures haben nichts mit Aktualisierungen der DB zu tun. Sie sind genauso nützlich beim Lesen von Daten, da SQL keinerlei Mittel für Programmablaufsteuerung mitbringt (if - then, do - while, for - next, ...). Du meinst wahrscheinlich Trigger - dies sind ereignisgesteuerte Prozeduren (INSERT, UPDATE, DELETE). Nö, ich weiß genau, von was ich schreibe. Waren ja auch nur als Beispiele gedacht, was MySQL fehlt. Zitat: ...., brauche ich auch keine Transaktionen, StoredProcedures, referentielle Integrität und all das, was in MySQL fehlt. ^^^^^^^^^^^^^^^^^ </Zitat>

Zitiere Dich bitte vollständig: Zitat: ... und solange nur gelesen wird aus der Datenbank, brauche ich ... <Dein Zitat> </Zitat> Da lag für mich der Schluss nahe, dass Du etwas verwechselt hast. Ich nutze nämlich Stored Procedures ziemlich häufig für reine Lese- Operationen. Jan P.S.: [1] Warum reagierst Du so aggressiv? [2] Ich habe nicht deshalb so ausführlich geantwortet, weil ich _Dich_ schulmeistern wollte, sondern weil ich den Thread nicht in für den Fragesteller (nach eigenen Aussagen SQL-Newbie) völlig unverständliches Fach-Chinesisch abgleiten lassen wollte. [3] Offensichtlich OT, es interessiert sich außer uns wohl keiner mehr dafür. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Steffen Dettmer wrote:

Ist MySQL überhaupt _richtig_ frei? Mir hat mal jemand erzählt, die Lizenz hättet irgenteinen "Haken" oder so?

Nein. mySQL ist kommerziell. Es ist lediglich Lizenzkostenfrei, wenn ein Webserver der einzige Client ist. Das mySQL-Team will damit freie, datenbankgestütze Webserver fördern. -Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Stefan Krister wrote:

Hallo Marc,

Marc Schiffbauer schrieb:

...

Nein. mySQL ist kommerziell. Es ist lediglich Lizenzkostenfrei, wenn ein Webserver der einzige Client ist.

könntest Du dazu bitte auch die Quelle verraten?

Hallo Steffan, http://web.mysql.com/Manual_chapter/manual_Licensing_and_Support.html#Web_se... (kurze Seite, lange URL) http://web.mysql.com/Manual/manual.html#Web_server (lange Seite kurze URL) ;-) für Privat ist es allerdings auch frei... -Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On Tue, Apr 18, 2000 at 08:05:35PM +0200, Jan Trippler wrote:

On Die, Apr 18, 2000 at 05:13:39 +0200, Wolfgang Wagner wrote:

Hallo Jan,

Es gibt schon einige Features, die mir für komplexere DB-Anwendungen fehlen würden, für die Mehrzahl der DB-Anwendungen im Int[er/ra]net reicht mySQL aber aus. Wenn es um ausgewachsene kaufmännische Anwendungen geht, würde ich derzeit immer auf andere DBMS zurückgreifen (unter Linux: Informix, Oracle, Interbase, Adabas, ...).

und was hälst Du von eine Intenetshop-Lösung auf MySQL-Basis als Warenkorbspeicher (viele Änderungen in kurzer Zeit aber dabei nur lesend, oder schreibend. Zudem wird der DAtensatz jedesmal komplett geupdatet, der geschrieben wird (bei meiner Version ist es jedenfalls so! um diese Problem zu umgehen.) Als Artikeldtembank, die vor dem Update gelöscht und dann neu erzeugt wird, ist MySQL ja sehr schnell. Wenn es auch schneller sein könnte (Hardware steht da im Weg!). -- M.f.G. Marcus Registered Linux-User : 136595 Mail : mailings-suse@gmx.de Etikette per Mail | mailto: mailings-suse@gmx.de Bitte keine CC Danke! / \ subject: send etikette --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On Don, Apr 20, 2000 at 09:44:33 +0200, Steffen Dettmer wrote:

* Marcus Maul wrote on Thu, Apr 20, 2000 at 19:40 +0200:

...

und was hälst Du von eine Intenetshop-Lösung auf MySQL-Basis als Warenkorbspeicher (viele Änderungen in kurzer Zeit aber dabei nur

Was passiert, wenn Dein Warenkorb dann nur zur Hälte in der Datenbank steht? z.B. Artikelname ohne Nummer und Preis oder so? IMHO ist das zumindestens sehr unsauber.

Ich würde wirklich gerne mal wissen, welche Vorteile MySQL gegenüber PostgreSQL hat. Nachteile hatten wir ja genug :)

Aber mySQL scheint häufig eingesetzt zu werden, ich kann mir nicht vorstellen, daß solche Entscheidungen nicht sorgfältig bedacht werden.

Solche Entscheidungen werden nicht nur auf der Basis der Technologie gefällt. Das spielt nach meiner Erfahrung im Gegenteil die kleinste Rolle :-( Eine einfache Warenkorblösung kann man sich sicher auf der Basis von mysql vorstellen. Ein Warenkorb wird ja benutzerabhängig gefüllt. Haarig würde es werden, wenn gleich Bestände online aktualisiert werden sollen oder z. B. artikelbezogene Statistiken sofort online abgefüllt werden. Du musst also kalkulieren: - Es sollten keine Zugriffe auf gemeinsam genutzte Daten vorkommen (Bestände, Titelstamm, Statistiken, ...) - Der Bestellvorgang sollte so abgeschlossen werden, dass an irgendeinem Punkt für den Kunden klar ist: Ich habe 10 Hochseeyachten, 25 Wolkenkratzer und 4 Regierungen bestellt, wenn ich jetzt auf OK drücke, dann geht das raus; oder er kriegt eine Mail mit der Auftragsbestätigung. Damit verhinderst du, dass Bestellungen nur halb verarbeitet werden (siehe Steffens Mails dazu). Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com