MySQL 4.0.24 Frust

[hkl]

Hallo !

Es gibt so Tage da sollte man als Programmierer vielleicht die Haende von der Tastatur lassen.

Arghhhh....

Kann mir bitte jemand sagen was an MySQL so toll ist , dass sich das als de-facto Standard etablieren konnte ?

• keine Views
• keine Trigger
• keine Stored Procedures

( Ja, ich weiss, mit v5 soll mehr gehen )

Das weiss ich auch alles und ich versuch damit zu leben.

Aber dass MyISAM keine referentielle Integritaet unterstuetzt ist schon HEFTIG !

Ein ON DELETE CASCADE Griff nicht, daran hab ich's gemerkt.
Natuerlich hilft RTFM, aber mal ernsthaft, rechnet Ihr mit sowas ?

Hab den Vormittag mit der Konfiguration von InnoDB ( die Engine unterstuetzt Ref. Integritaeten ) gekaempft - mit halbem Erfolg : Raw oder Filedevices werden nicht initialisert...  da sollen irgendwelche Logfiles nicht gleichzeitig erstellt werden koennen. Trotz Platz und Rechten.
( MySQL 4.0.24  / Debian Sarge 3.1r1 . Just FYI. Dies ist KEINE Frage. )

Dann darf man bloss nicht Indices auf FK - columns vergessen ( 4.0.24 ) - aber seis drum; sind eh sinnvoll.

Also steh ich jetzt vor der Wahl

• Fuer Referentielle Integritaet gefaelligst selbst zu sorgen
• oder mich mit der langsameren Engine zufrieden zu geben, die zudem beim schon bei der Basiskonfiguration rumzickt.

Wie schoen, dass man Alternativen hat... :-(

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

Wenn nicht, auch gut.

Auf alle Faelle ein schoenes WE an alle !

LG

Holger

[DB-Meister]

Kann mir bitte jemand sagen was an MySQL so toll ist , dass sich das als de-facto Standard etablieren konnte ?

• keine Views
• keine Trigger
• keine Stored Procedures

Ist doch normal für alte MySQLs.

( Ja, ich weiss, mit v5 soll mehr gehen )

Geht auch.

( MySQL 4.0.24  / Debian Sarge 3.1r1 . Just FYI. Dies ist KEINE Frage. )

Version 4.0 ist von ANNO! Wenigstens 4.1 zu installieren, besser noch 5.1, wäre erste Bürgerpflicht.

Die Schuld für unzulängliche Programmierkenntnisse deinerseits im Hinblick auf die Fähigkeiten von MySQL jetzt MySQL in die Schuhe zu schieben ist schon ziemlich schwach. Wenn du so alte Versionen benutzt: Selbst Schuld!

Grüße vom DB-Meister

[hkl]

Hey, Du "Meister",

komm mir heute besser mal nicht komisch:

Die Schuld für unzulängliche Programmierkenntnisse deinerseits im Hinblick auf die Fähigkeiten von MySQL jetzt MySQL in die Schuhe zu schieben ist schon ziemlich schwach. Wenn du so alte Versionen benutzt: Selbst Schuld!

Wie weit es allerdings Datenbankverstaendnis reicht kan man auch anzweifeln

• weder MyISAM unter 4.1 noch 5.x unterstuetzen referentielle Integritateten
• dass ON DELETE CASCADE auf MyISAM Tabellen dann legal ist ganz klar eine konzeptionelle Schwaeche

Weisst Du "Meister" eigentlich was "Referentielle Integritaet" bedeutet oder wolltest Du nur mal schlaubergern  ?

Leg Dich besser wieder hin !

Holger

[lulu]

Ahoi,

• weder MyISAM unter 4.1 noch 5.x unterstuetzen referentielle Integritateten

MySQL nutzt unterschiedliche storage engines.
MyIsam unterstützt das grundsätzlich nicht, dass hat nichts mit der Versionsnummer zu tun.
Dafür gibt es die InnoDB engine.

Viele Grüße

lulu

[hkl]

Hallo lulu!

Ahoi,

• weder MyISAM unter 4.1 noch 5.x unterstuetzen referentielle Integritateten

MySQL nutzt unterschiedliche storage engines.

Schon klar, nur wen ich mal das Forum zu InnoDB ueberblicke, ist mit InnoDB schon so ziemlich alles schiefgegangen was schiefgehen kann: "foreign key problem", "deadlock", "log sequence error"...

MyIsam unterstützt das grundsätzlich nicht, dass hat nichts mit der Versionsnummer zu tun.

Aber warum dann die Definition von FK auf MyISAM-Tabellen legal ist, entzieht sich meinem Vestaendis. Kompatibilitaetserwaegungen koennen da nicht ausschlagegebend sein.

Gruesse

Holger

[dedlfix]

echo $begrüßung;

Kann mir bitte jemand sagen was an MySQL so toll ist , dass sich das als de-facto Standard etablieren konnte ?

Es ist "überall" installiert und es reicht für die Anforderungen der meisten Nutzer aus. Wenn dir das System zu wenig Leistungsmerkmale bietet, solltest du dich nach den reichlich vorhandenen Alternativen umschauen. "Reichlich" natürlich nur dann, wenn du nicht, aus welchen Gründen auch immer, an die von erwähnte Version gebunden bist.

Eigentlich reicht den meisten Anwendern auch SQLite, das hat noch weit weniger Möglichkeiten als MySQL.

echo "$verabschiedung $name";

[hkl]

Hallo dedlfix !

echo $begrüßung;

Kann mir bitte jemand sagen was an MySQL so toll ist , dass sich das als de-facto Standard etablieren konnte ?

Es ist "überall" installiert

Es ist ueberall installiert WEIL es der de-facto Standard ist. Ich wueste gerne mal ein Alleinstellungsmerkmal des Sytems durch das es dazu geworden ist.

Bislang hab ich wegen des geringen Leistngsumfanges immer von MySQL Abstand genommen. Jetzt muss ich's leider einmal einsetzen - und siehe, der Aerger geht schon wieder los.

Wenn's jetzt nicht MySQL hiesse und

• keine Views
• keine Trigger
• keine SP's
• und nicht mal ausreichend dokumentiert ist, dass R.I. nicht "von Haus aus" implementitiert sind

wuedest Du dann die DB einsetzen ?
SQL ist das nicht mehr.

• in der Doku zu MyISAM lese ich nichts davon das hier vom Standard abgewichen wird. Das ist nicht "irgendein" Feature - das ist SQL92 Standard.
  Bei InnoDB steht es als "Feature" aber das hiess fuer mich noch nicht das es bei MyISAM fehlt.

Die ganze Idee finde ich etwas absurd - Relationale Datenbanken ohne strukturelle Unberstuetzung fuer Relationen ?

Genau steht's uebrigens bei CREATE TABLE - aber soll das der Sinn eines Standards sein sein, dass ich fuer jede DB die SQL-Syntax Refernz nochmal durchmal lesen muss obwohl ich schon 1001 DDL Statement geschrieben habe ? Wohl kaum.

und es reicht für die Anforderungen der meisten Nutzer aus.

Kann es sein dass nicht alle DB die im Netz sind auf constraint violations getestet sind ?

Wenn dir das System zu wenig Leistungsmerkmale bietet, solltest du dich nach den reichlich vorhandenen Alternativen umschauen.

;-)

Wenn's mit dem kleinen Hammer nicht geht nimmt man den groesseren ?!?
( Das war mir jetzt aber irgendwie auch schon klar.... :-) )

"Reichlich" natürlich nur dann, wenn du nicht, aus welchen Gründen auch immer, an die von erwähnte Version gebunden bist.

Bin ich leider. Sonst wuerde ich's heute noch auf Postgres portieren.

Auf meiner Zielplatform habe ich uebrigens alle Storage Engines - ausser InnoDB. :-(

Also - auf der Entwicklungsplatform mit InnoDB arbeiten ( oder mit einer richtigen Datenbank - Postgres, MSSQL o.ae.) - alle Seiten in eine TEXT-column packen und auf der Zielplatform PHP ganz vorsichtig nur noch auf eine Tabelle mit einem Schluessel und einer TEXT-column zugreifen lassen.

Constraints "von oben" in die Anwendung reinzuprogrammieren kann's ja wohl nicht sein. Das mach ich einfach nicht im Jahr 2006.

Super Struktur ! :-(
Super DB !

Eigentlich reicht den meisten Anwendern auch SQLite, das hat noch weit weniger Möglichkeiten als MySQL.

echo "$verabschiedung $name";

Danke fuer Deine Antwort !

Gruss

und schoenes WE !

Holger

[dedlfix]

echo $begrüßung;

Wenn's jetzt nicht MySQL hiesse und

• keine Views
• keine Trigger
• keine SP's
• und nicht mal ausreichend dokumentiert ist, dass R.I. nicht "von Haus aus" implementitiert sind

wuedest Du dann die DB einsetzen ?

Ja, ich setzte (Konjunktiv, nicht Präteritum) es ein, weil diese Leistungsmerkmale zwar nett sind, ich aber auch ohne sie auskomme.
Und dass R.I. nur mit der InnoDB geht und ansonsten die dies betreffenden Befehlsbestandteile ignoriert werden ist bei MySQL dokumentiert.

• in der Doku zu MyISAM lese ich nichts davon das hier vom Standard abgewichen wird. Das ist nicht "irgendein" Feature - das ist SQL92 Standard.
  Bei InnoDB steht es als "Feature" aber das hiess fuer mich noch nicht das es bei MyISAM fehlt.

Du solltest mittlerweile gelernt haben, das man bei nicht aufgezählten Funktionen davon ausgehen kann, dass sie nicht enthalten sind. Wenn nicht, war das eben eine gute Idee, um diesen Punkt noch mal in "deiner Datenbank" klarzustellen :-)

Wenn dir das System zu wenig Leistungsmerkmale bietet, solltest du dich nach den reichlich vorhandenen Alternativen umschauen.
Wenn's mit dem kleinen Hammer nicht geht nimmt man den groesseren ?!?
( Das war mir jetzt aber irgendwie auch schon klar.... :-) )

Andersrum wird ein Schuh draus. Warum soll man überall solche Boliden wie Oracle inklusive dessen Kosten installieren, wenn sich die Anwender auch mit dem Funktionsumfang von MySQL 3 (in Worten: drei) oder SQLite zufrieden geben?

Auf meiner Zielplatform habe ich uebrigens alle Storage Engines - ausser InnoDB. :-(

Klingt nach einem (zu billigen) Provider. InnoDB braucht kein Mensch ... :-)

Gib dir ein wenig Mühe beim Programmieren, dann klappt das auch mit der referenziellen Integrität deiner Daten, auch wenn sie nicht durch die Datenbank sichergestellt werden.

echo "$verabschiedung $name";

[hkl]

Hallo dedlfix !

Du solltest mittlerweile gelernt haben, das man bei nicht aufgezählten Funktionen davon ausgehen kann, dass sie nicht enthalten sind.

Ein Standard ist ein Standard ist - ein Standard.
SQL ist ein Standard. Vielleicht der erste in der IT der wirklich was gebracht hat.
Ein legales Statement ist ein ...
Keine Fehlermeldung bedeutet dass kein Fehler...

Wenn nicht, war das eben eine gute Idee, um diesen Punkt noch mal in "deiner Datenbank" klarzustellen :-)

O.K: dann ueberleg ich mir beim Lesen eines Textes in Zukunft alle Dinge die NICHT in dem Text stehen, und definier dafuer mentale Trigger !
Da wird "meine Datenbank" allerdings bald SEHR viele Transaktionen haben.

Vielleicht fuehr vorher ein

DELETE FROM standards

aus. :-)

Wenn dir das System zu wenig Leistungsmerkmale bietet, solltest du dich nach den reichlich vorhandenen Alternativen umschauen.
Wenn's mit dem kleinen Hammer nicht geht nimmt man den groesseren ?!?
( Das war mir jetzt aber irgendwie auch schon klar.... :-) )

Andersrum wird ein Schuh draus. Warum soll man überall solche Boliden wie Oracle inklusive dessen Kosten installieren, wenn sich die Anwender auch mit dem Funktionsumfang von MySQL 3 (in Worten: drei) oder SQLite zufrieden geben?

Warum nimmst Du dies Ding eigentlich in Schutz ? Hast Du's so lieb gewonnen ? :-)

Auf meiner Zielplatform habe ich uebrigens alle Storage Engines - ausser InnoDB. :-(

Klingt nach einem (zu billigen) Provider. InnoDB braucht kein Mensch ... :-)

Langsam kommt ein anderer Provider wirklich in Betracht. Das gibt mir echt den Rest.
Aber auch da seh ich MySQL mit Skepsis - wenn man die Relationalitaet einer relationalen Datenbank als Modul (!) auslegt, kann's halt sein dass jemand dies Modul wegkonfiguriert.

Gib dir ein wenig Mühe beim Programmieren,

Das tu ich nie. Das kann gar nicht. Dafuer bin ich viel zu dumm.

dann klappt das auch mit der referenziellen Integrität deiner Daten

Ach komm dedlfix, das kannst DU doch gar nicht ernst meinen. :-)
Suchalgorithmen nachbauen die sonst tief in der Datenbank liegen und ohne Trigger oder aehnliches "von oben" programmatisch an das Problem rangehen ?

Willst Du mich heute flachsen ? :-)

echo "$verabschiedung $name";

Gruesse

Holger

[Vinzenz Mai]

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)
   - keine Berücksichtigung der Klammern bei Mehrfachjoins
     d.h. Du kannst Klammern setzen, das wirft keinen Fehler,
     sie zeigen aber auch keine Wirkung :-)
   - 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.

=> 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.

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.

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

[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

[hkl]

Domains fehlen auch.
Waere gerade bei XML-Verarbeitung ( ID/IDREF ) wirklich nett.
ALSO WIRKLICH !

:-)

Gruesse

Holger