MySQL 5: Welcher Unterschied zur MySQL 4?

[Der_Jan]

Moin,
mein Webspace-Provider fragt mich im Benutzermenu, ob ich eine MySQL 4 oder 5 anlegen möchte. Habe bis heut immer mit der Version 4 gearbeitet und bin mir nun nicht sicher: Funktioniert die 5 genauso wie die 4 oder sind die Unterschiede so erheblich, dass man sich in 5 erst einarbeiten muss?

Gruß
Der Jan

 

[Eppi]

Ich meine Views und Stored Procedures wären neu. Bin aber nicht 100%ig sicher.

gruss Eppi

PS: Ich behaupte mal, dass eine Einarbeitung nicht nötig ist! Machst du PHP oder JSP, oder was?

 

[master_p]

Ich glaube der größte Unterschied (für den Administrator) ist, dass die Passwortverwaltung bei MySQL5 anders läuft und man deshalb entweder mit "-oldpasswords" konpiliert oder aber die Passwörter neu vergibt, denn man kann sich nicht mehr einloggen, wenn man es mit einem 4er Account bei einer 5er versucht, wo der Dump (einfach so) eingespielt wurde.

Ansonsten sind eigentlich nahezu alle alten Funktionen gleich geblieben, von daher macht es keinen allzu großen Unterschied für laufende Scripte, ob sie auf einer 4er oder 5er DB laufen. Wie gesagt, hauptsache die Passwörter werden beim Dump korrekt gesetzt.

 

[Eppi]

Die old-Password Problematik existiert schon seid mindestens 4.1. Falls das eine Hilfe für einen DB-Umzug ist.


Gruss Eppi

 

[wegus]

mit der Version5 wird aus mysql langsam ein Datenbanksystem, statt nur ein Datencontainer. Subselects gehen glaub ich schon länger, seit wann mysql richtige joins unterstützt weiß ich nicht genau, aber Version 5 beherrscht glaub ich auch schon Stored Procedures und views oder? Fehlen nur noch Trigger und dann wird mysql langsam interessant. Ich bin sicher bei mysql.com gibt es eine feature-Seite die die Neuerungen auflistet!

 

[Gunter_S]

trigger gibt's doch bei MySQL 5 schon.
nach mysql.com:

MySQL 5.0 Key Features:
* Stored Procedures
* Triggers
* Views
* Information Schema
* Archive Storage Engine

Gunter

 

[wegus]

triggers gibt's doch bei MySQL 5 schon.

mir war so als wären die erst für 5.1 geplant, dann wird mysql langsam interessant

 

[Gunter_S]

Ich fände es sehr toll, wenn MySQL mit Objekten wie Oracle umgehen könnte.

 

[moses_78]

Was zur Hölle sind "trigger" bei Datenbanksystemen?

Danke im Vorraus,
moses

 

[Gunter_S]

ein klassisches Beispiel sind die Preisentwicklungstools bei E-Shops.
Man definiert einen Trigger auf der Tabelle aller Artikel, so dass immer wenn ein Preis geändert wird, automatisch in einer zweiten Tabelle mitgeloggt wird, wann sich der Preis wie geändert hat.

also statt manuell folgendes auszuführen:

SELECT costs FROM article WHERE id=[i]xyz[/i];
INSERT INTO preislog (oldcosts, newcosts, changedon) VALUES ([i]aktueller_preis[/i], [i]neuer_preis[/i], NOW());
UPDATE article SET costs=[i]neuer_preis[/i] WHERE id=[i]xyz[/i];

macht man beim Anlegen der Tabellen folgendes:

CREATE TABLE preislog (
  id int PRIMARY KEY,
  oldcosts float,
  newcosts float,
  changedon date
);
CREATE OR REPLACE TRIGGER Package_Update BEFORE
    UPDATE ON artikel
    FOR EACH ROW WHEN (new.costs != old.costs) Begin
    insert into preislog(id,oldcosts,newcosts,changedon)
   values(:new.id,:old.costs,:new.costs,sysdate);
End;

und danach kann man ein einfaches

UPDATE article SET costs=[i]neuer_preis[/i] WHERE id=[i]xyz[/i]

machen und alles weitere geschieht automatisch im Hintergrund.

Die SQL-Statements waren jetzt aus Oracle, bei MySQL wird's aber dann wohl so ähnlich sein, da habe ich Trigger selbst noch nicht benutzt.

Gunter

 

[moses_78]

ein klassisches Beispiel sind die Preisentwicklungstools bei E-Shops.
Man definiert einen Trigger auf der Tabelle aller Artikel.....

Gunter, vielen Dank für deine gute Erläuterung
Ein Trigger synchronisiert also im Grunde nur zwei Werte in verschiedenen
Tabellen.

 

[wegus]

Ein Trigger synchronisiert also im Grunde nur zwei Werte in verschiedenen
Tabellen.

Nein! Das muß nicht so sein! Ein Trigger ist ein Ereignis, daß man definieren kann ( ON INSERT, UPDATE einer Spalte) und dieser Spalte kann man eine Prozedur in SQL ( stored Procedure genannt) zuordnen. Ob diese dann eine 2te Spalte aktualisiert oder z.B. eine email verschickt ist dann egal. Auch die Replikation zwischen zwei entfernten Servern kann mittels Triggern gemacht werden. Oder ein logging ( wie oft wird ein Parameter von welchem Benutzer geändert) kann damit durchgeführt werden. Der Nutzen solcher Events ist ähnlich universell wie mousclicks in einer GUI! Für komplexere DB's unersätzlich!

 

[Jakob]

Hallo,

habe auf MySQL 5 migriert und jetzt ein seltsames Problem. Habe einen kleinen Join:

SELECT p.Produkt_ID, t.de_Typ AS Typ, n.de_Name AS Name
FROM Produkte AS p
JOIN Typen AS t ON (p.Typ_ID = t.Typ_ID)
LEFT JOIN Namen AS n ON (p.Name_ID = n.Name_ID)
WHERE p.Produkt_ID = 1

funktioniert im 4er ganz normal, im 5er wird mir folgender Fehler ausgegeben:

You have an error in your SQL syntax near 'ON ( p . Typ_ID = t . Typ_ID ) LEFT JOIN Namen AS n ON ( p . Name_ID = n . Na' at line 1

Seht ihr da was? Ich seh keinen Fehler.

Hat sich bei der Behandlung des normalen „JOIN“ Befehls was geändert? In der Reference Guide finde ich nichts. Mache ich statt dem „JOIN“ ein „LEFT JOIN“ funktioniert's, aber das soll ja kein „LEFT“ sein.

UPDATE: Ok, hab jetzt doch was gefunden. Noch verstehe ich die Neubehandlung nicht ganz. Ein „LEFT“ hier und ein „CROSS“ da wirken jedoch Wunder.

 

[catvarlog]

wenn du eine mysql-version kleiner als 4.1 verwendest ist ein großer unterschied zwischen 4 und 5 die handhabung von timestamps. das kann ein ganz großes problem sein.

From MySQL 4.1.0 on, TIMESTAMP display format differs from that 
of earlier MySQL releases:

TIMESTAMP columns are displayed in the same format as DATETIME 
columns. In other words, the display width is fixed at 19 characters, 
and the format is YYYY-MM-DD HH:MM:SS.

http://dev.mysql.com/doc/refman/4.1/en/timestamp-4-1.html

 

[Jakob]

Hallo,

daran liegt es nicht. Vielmehr daran:

Incompatible change: Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. The changes include elimination of redundant output columns for NATURAL joins and joins specified with a USING clause and proper ordering of output columns. These changes make MySQL more compliant with standard SQL. However, they can result in different output columns for some joins. Also, some queries that appeared to work correctly prior to 5.0.12 must be rewritten to comply with the standard. For details about the scope of the changes and examples that show what query rewrites are necessary, see Section 13.2.7.1, 'JOIN Syntax'.

Muss mich nochmal neu einlesen.

http://dev.mysql.com/doc/refman/5.1/en/join.html

 

[Jakob]

Vielleicht red ich hier ja nur mit mir, aber falls es mal jmd interessiert:

In MySQL 5 wird die JOIN-Syntax strikter oder zumindest anders geparst.

In 4 funktioniert dies ganz normal:

SELECT *
FROM a
JOIN b
ON b.ID = a.ID
AND b.nr < a.nr
LEFT JOIN c
ON c.ID = a.ID
AND c.nr > a.nr

So gibt das einen Fehler in 5.

Lösung für mich:

SELECT *
FROM a
INNER JOIN b
ON (b.ID = a.ID
AND b.nr < a.nr)
LEFT JOIN c
ON (c.ID = a.ID
AND c.nr > a.nr)

Klammern + INNER