MySQL Update

[lvl]

Hi ihrs ;)

Nach einem Update von MySql 4.0 auf 5.1 habe ich Probleme mit einigen SQL-Statements.

Mir ist aufgefallen, das die INNER JOINs in der richtigen Reihenfolge stehen müssen, da er sonst den Alias nicht erkennt.

Dies war in MySQL 4.0 nicht nötig.

Kann es sein, dass es in MySQL 5.1 eine Einstellung gibt, bei der die Reihenfolge wieder egal ist?

[Rouven]

Hello,

Mir ist aufgefallen, das die INNER JOINs in der richtigen Reihenfolge stehen müssen, da er sonst den Alias nicht erkennt.

kannst du das mal bitte ausführen, da kann ich mir gerade herzlich wenig drunter vorstellen.

MfG
Rouven

[lvl]

kannst du das mal bitte ausführen, da kann ich mir gerade herzlich wenig drunter vorstellen.

Bsp.:

SELECT t1.feld1, t2.feld2, t3.feld3

FROM tabelle1 t1

INNERJOIN
tabelle3 t3
ON
t3.feldx = t2.feldx

INNER JOIN
tabelle2 t2
t2.feldx = t1.feldx

So funktioniert es nicht.
Fehler Unknown t2.feldx

Wenn die INNER JOINs nun getauscht werden läuft es.

[Rouven]

Hello,

Wenn die INNER JOINs nun getauscht werden läuft es.

OK, macht IMHO Sinn, es verwundert mich mehr, dass es vorher in dieser Konstellation geklappt hat, wäre nie auf die Idee gekommen, das zu versuchen. Demnach lautet meine Antwort: vermutlich gibt es keine Einstellung, um das Verhalten umzukehren.

MfG
Rouven

[Sven Rautenberg]

Moin!

SELECT t1.feld1, t2.feld2, t3.feld3

FROM tabelle1 t1

INNERJOIN
tabelle3 t3
ON
t3.feldx = t2.feldx

An dieser Stelle greifst du auf t2 zu, ohne dass t2 bislang definiert wurde. Das ist von der Reihenfolge der Joins her eher ungewöhnlich, und der Austausch der Reihenfolge ist mindestens dem Verständnis des SQL förderlich.

Meine Erwartung wäre, dass man in der ON-Bedingung nur Tabellen verwendet, die bis hierhin schon aufgeführt wurden.

INNER JOIN
tabelle2 t2
t2.feldx = t1.feldx

- Sven Rautenberg

[lvl]

An dieser Stelle greifst du auf t2 zu, ohne dass t2 bislang definiert wurde. Das ist von der Reihenfolge der Joins her eher ungewöhnlich, und der Austausch der Reihenfolge ist mindestens dem Verständnis des SQL förderlich.

Ist klar, aber wie ich schon sagte, es funktionierte in der MySQL 4.0 Version. Und im laufe der Zeit wurde nicht darauf geachtet. Es konnte auch durch ein erweitern des SQLs entstehen. Da MySQL 4.0 nicht meckert, hat es auch keiner als falsch angesehen.

Jetzt nach der Umstellung wird es einem aber um die Ohren gehauen. Da es in 4.0 möglich war und nun nicht, habe ich gehofft/hoffe ich, das es eine Einstellung gibt, die das auch unter 5.1 ermöglicht.

[Vinzenz Mai]

Hallo

Jetzt nach der Umstellung wird es einem aber um die Ohren gehauen. Da es in 4.0 möglich war und nun nicht, habe ich gehofft/hoffe ich, das es eine Einstellung gibt, die das auch unter 5.1 ermöglicht.

Soweit ich das überblicke, handelt es sich um eine inkompatible Änderung in MySQL 5.0.12, die ich explizit begrüße.

http://dev.mysql.com/doc/refman/5.0/en/news-5-0-12.html und das referenzierte Dokument http://dev.mysql.com/doc/refman/5.0/en/join.html.

Ich zitiere ein Beispiel, das genau Deinen Fall trifft:

<zitat>
Previously, the ON clause could refer to columns in tables named to its right. Now an ON clause can refer only to its operands.

Example:

CREATE TABLE t1 (i1 INT);
CREATE TABLE t2 (i2 INT);
CREATE TABLE t3 (i3 INT);
SELECT * FROM t1 JOIN t2 ON (i1 = i3) JOIN t3;

Previously, the SELECT statement was legal. Now the statement fails with an Unknown column 'i3' in 'on clause' error because i3 is a column in t3, which is not an operand of the ON clause. The statement should be rewritten as follows:

SELECT * FROM t1 JOIN t2 JOIN t3 ON (i1 = i3);
</zitat>

Ich finde diese Änderung extrem nützlich, weil MySQL ab 5.0.12 endlich vernünftige Ergebnisse bei Join-Operationen liefert. Sowas _nicht_ konfigurierbar zu halten, ist selbstverständlich eine gute Idee, weil es ansonsten unvorhersagbare Ergebnisse zu Folge hätte.

Ja, MySQL 5.0.x hat viele Anwendungen, die sich auf kaputtes Verhalten von
MySQL verlassen haben, auf den Boden der Tatsachen geholt:

Die Anwendungen waren anschließend kaputt.

Freundliche Grüße

Vinzenz

[lvl]

Sowas _nicht_ konfigurierbar zu halten, ist selbstverständlich eine gute Idee, weil es ansonsten unvorhersagbare Ergebnisse zu Folge hätte.

Ob sowas aus sicht von Unternehmen eine so gute Idee ist, darüber lässt sich ja streiten.
Zumindest für den Umbau von einer älteren Version auf eine neue Version, würde eine Einstellmöglichkeit von Vorteil sein, da nicht alle den Masterplan bei der umstellung verfolgen.

Dennoch vielen Dank für die Info. ;)

[Rouven]

Hello,

Zumindest für den Umbau von einer älteren Version auf eine neue Version, würde eine Einstellmöglichkeit von Vorteil sein, da nicht alle den Masterplan bei der umstellung verfolgen.

lässt sich nicht in den Wind schlagen - ABER: man sieht ja bei register_globals wohin das führt, die meisten stellen einfach aus Bequemlichkeit wieder auf "on" kümmern sich nicht mehr drum und müssen dann halt später den Hammer ertragen.

Genaugenommen ist es anders herum eine Fahrlässigkeit auf eine neue MySQL Version umzustellen ohne vorher die Konsequenzen zu prüfen. Was meinst du, warum Firmen oftmals noch jahrelang auf älteren Softwareversionen arbeiten als am Markt verfügbar. Das hat nicht nur finanzielle Gründe, sondern es muss auch sichergestellt sein, dass man sich durch ein Update nicht schlechter stellt als vorher indem man Anwendungen außer Gefecht setzt. Der IE6 (und bei anderen vielleicht sogar ein IE5) ist in Unternehmen heutzutage noch weit verbreitet, weil einige Weboberflächen mit einem IE7 nicht problemlos zusammenarbeiten oder zumindest nicht freigegeben wurden.

MfG
Rouven

[Sven Rautenberg]

Moin!

Sowas _nicht_ konfigurierbar zu halten, ist selbstverständlich eine gute Idee, weil es ansonsten unvorhersagbare Ergebnisse zu Folge hätte.

Ob sowas aus sicht von Unternehmen eine so gute Idee ist, darüber lässt sich ja streiten.
Zumindest für den Umbau von einer älteren Version auf eine neue Version, würde eine Einstellmöglichkeit von Vorteil sein, da nicht alle den Masterplan bei der umstellung verfolgen.

Du hast bei deiner Umstellung von 4.0 auf 5.1 sowieso eine ganz wichtige Feature-Grenze überschritten: Von 4.0 auf 4.1 hat MySQL nämlich die Behandlung von diversen Zeichencodierungen (auch Multibyte-Codierungen wie UTF-8) gelernt.

Allein dieses neue Feature, dass man in allen Versionen ab 4.1 nicht mehr einfach ignorieren kann, sondern zwingend berücksichtigen muß, erfordert erhöhte Aufmerksamkeit bei der Umstellung.

- Sven Rautenberg