MySQL 4.0.24 Frust

[hkl]

Hallo Vinzenz !

Hallo Holger,

• keine Views
• keine Trigger
• keine Stored Procedures

Du hast bei 4.0.x noch wichtiges vergessen

- keine Subselects, (erst ab 4.1.x)

Danke fuer die Hinweise auf die Fallstricke !

- keine Berücksichtigung der Klammern bei Mehrfachjoins
     d.h. Du kannst Klammern setzen, das wirft keinen Fehler,
     sie zeigen aber auch keine Wirkung :-)

Das erinnert "konzeptionell" an den Umgang mit den auf MyISAM obsoleten Integritaeten.

MySQL AB bietet doch sogar Consulting an - wie vekauft man das denn ?!?

- vernünftige Join-Interpretation ab Version 5.0.12

oder grundsätzlich das schlampige Verhalten bei Verwendung nicht aggregierter Spalten, die nicht in der GROUP-BY-Klausel auftreten - mein Liebling in der Kategorie "it's not a bug, it's a feature".

Aber dass MyISAM keine referentielle Integritaet unterstuetzt ist schon HEFTIG !

Sorry, aber auch das wurde früher sogar als Feature angepriesen.

Klar, schnellere inserts, weil kein CHECK CONSTRAINTS passiert ! :-|
Von schnellen inserts hab ich auch schon oft gehoert....

=> Kann mir bitte jemand sagen was an MySQL so toll ist ? <=

Warum hat sich VHS durchgesetzt? Bei vielen einfachen Webanwendungen war gar nicht mehr notwendig als das, was MySQL 3.23.x bot :-) MySQL war da, die Lizenzbedingungen annehmbar und bezahlbar.

Das ist doch kein SQL mehr - es haelt sich nicht an den Standard. Punkt.
Da kann's meinetwegen noch so billig sein.

Ausserdem wird das ja sogar bei n MegaEuro Projekten eingesetzt - das darf doch wohl nicht wahr sein ! Auch und grade schon lange vor v5.

Wuerde wirklich gerne mal wissen wieviele Programmierer sich schon auf die Constraint-Clause verlassen haben und damit online gegangen sind.
( Obwohl man das natuerlich testen muesste, ob die eignene Fehlerbehandlung fuer violations greift - da muesste man's dann eigentlich merken )

Auf sowas kommt man doch nicht. Wenn man ein Statement formuliert geht man doch implizit davon aus dass das nicht irgendwie "ignoriert" wird...

Warum kannst Du den Kunden (oder was auch immer) nicht mit den entsprechenden Argumenten davon überzeugen, auf eine deutlich aktuellere MySQL-Version, ich empfehle mindestens die 5.0.12 (s.o.), umzusteigen? Natürlich mit der InnoDB-Engine.

Wenn das ein "Kunde" waere, dann gute Nacht...

Es geht um den Server vno Sourceforge, und da alles verboten was nicht explizit erlaubt.
( Also etwa so wie "liberalen" Amerika... )

Admins sind halt nicht immer Programmierer - ich stell mir das so vor

InnoDB "kann" Raw Devices => Das klingt gefaehrlich !!!
=> Bloss schnell abschalten !

Nur um man einen Eindruck zu vermitteln wie eng die Maschine konfiguriert ist : ein CGI - Aufruf ( kein Redirect ) aus einem Skript AUF DEN GLEICHEN SERVER GELANGT nicht durch die Firewall.

Irgendein RPC - Aufruf aus einem Skript auf einem anderen Server GELANGT NICHT durch die Firewall.

Man hat Platz um sich (Perl)CPAN Module zu installieren - aber halt nicht mittels MCPAN - denn DAS GELANGT NICHT durch die Firewall.

Dass kein C-Compiler drauf ist, brauch ich nicht mehr zu erwaehnen, oder ?

Als ich heute morgen die Sache mit MyISAM bemerkte war mir instinktiv klar was passieren wuerde - namelich das InnoDB nicht unterstuezt wird.
War dann auch so.

Ach ja, ich habe schon meine Gründe dafür, bei Fragen hier im Forum zu MySQL fast reflexartig nach der Version zu fragen.

Freundliche Grüße

Vinzenz

Danke fuer Deine Warnungen weitere "features" betreffend,
und ein schoenes WE !

Gruesse

Holger