Tabelle Aktualisieren? -> MySQL

[SeeKing]

Nur als Vorwarnung:

Solltest du den Primary Key als Foreign in anderen benutzt haben, musst du die ID´s dort auch ändern (ziemlicher aufwand). Das kann mitunter tödlich enden. Die Datenbank kratzt es normalerweise wenig ob da ein paar ID´s zwischen drin fehlen. (Ist ja auch sinn des Autoincrements)

Also ich würde es lassen, du halst dir damit nur mehr Ärger an als es wirklich bringt. Wo man sowas machen kann ist wenn man ein kompletten DB-Reorg macht. Sowas macht man aber nur wenn so ein Fall eintritt wie ich ihn oben beschrieben habe oder wenn die IndexFiles flöten sind.

Gruss
MixTer

 

[Acriss]

danke für den Hinweis.
Ich werde das jetzt nach datum ordnen,
also ohne IDs, dann bleibt mir deswegen der ärger schonmal erspart^^
Aber, ich hab atm kein Plan wie ich das anstellen soll.

0000-00-00 00:00:00
Betreff: Willkommen
Hi, Willkommen auf dieser Homepage

Das ist meine Ausgabe.
Allerdings sollte das Datum auch angezeigt werden.
Und nicht 00000000
Was muss ich dann hier verändern?

$insert = "INSERT INTO news (betreff, news) VALUES ('$betreff', '$news')";

 

[lmarkus31]

Hallo,

auch wenn du es jetzt doch anders gelöst hast, noch eine kleine Bemerkung zu der angesprochenen referentiellen Integrität bzgl. Updates auf Primärschlüssel.

Nur als Vorwarnung:

Solltest du den Primary Key als Foreign in anderen benutzt haben, musst du die ID´s dort auch ändern (ziemlicher aufwand). Das dann mitunter tödlich enden. Die Datenbank kratzt es normalerweise wenig ob da ein paar ID´s zwischen drin fehlen. (Ist ja auch sinn des Autoincrements)

Wenn die Fremdschlüssel-Spalten mit Constraints ohne Aktualisierungsweitergabe o.ä. definiert wurden, sondern im "Standardmodus" (NO ACTION) , wird das Update fehlschlagen, wenn es nach dem Ausführen des Statements mind. einen Eintrag in der referenzierenden Tabelle gibt, der nicht auf einen Eintrag der Basistabelle mit dem PK verweist.

Bei sorgfältiger Planung der Datenbank definiert man bei den Tabellen, die eine Fremdschlüsselbeziehung zur upzudatenden Tabelle besitzen bspw. folgendermassen:

ALTER TABLE fktable
   ADD CONSTRAINT fk_basetable
   FOREIGN KEY (refid)
   REFERENCES basetable (id)
   ON UPDATE CASCADE;

Hierbei sorgt das RDBMS und im speziellen die "ON UPDATE CASCADE"-Klausel dafür, dass deine Fremdschlüsselbeziehung gültig bleibt und du dein Update auf der Basistabelle überhaupt durchführen darfst, da das RDBMS den Wert auf den neuen Wert setzt (in allen abhängigen Tabellen, die ein Fremdschlüssel-Constraint wie eben beschrieben besitzen).

Eine Alternative für manche Fälle wäre statttdessen die Klausel "ON UPDATE SET NULL". Dann würde das UPDATE-Statement auch durchlaufen, in der referenzierenden Tabelle würden aber die Datensätze, die ohne gültigen Verweis auf einen PK dastehen auf NULL gesetzt werden und könnten so nachträglich bearbeitet werden.

Markus

 

[Sparks]

@Inmarkus, das meinte ich mit der referentiellen Integrität...super erklärt.

@Acriss, noch zur Beantwortung Deiner letzten Frage.
Wenn Deine Datums-Spalte vom Typ DATETIME ist und 'erstellt' lautet:

INSERT INTO news ( betreff, news, erstellt ) VALUES ( '$betreff', '$news', NOW() )

Gruß, Sparks

 

[SeeKing]

Hallo,

auch wenn du es jetzt doch anders gelöst hast, noch eine kleine Bemerkung zu der angesprochenen referentiellen Integrität bzgl. Updates auf Primärschlüssel.




Wenn die Fremdschlüssel-Spalten mit Constraints ohne Aktualisierungsweitergabe o.ä. definiert wurden, sondern im "Standardmodus" (NO ACTION) , wird das Update fehlschlagen, wenn es nach dem Ausführen des Statements mind. einen Eintrag in der referenzierenden Tabelle gibt, der nicht auf einen Eintrag der Basistabelle mit dem PK verweist.

Bei sorgfältiger Planung der Datenbank definiert man bei den Tabellen, die eine Fremdschlüsselbeziehung zur upzudatenden Tabelle besitzen bspw. folgendermassen:

sql Code:

1. ALTER TABLE fktable
2. ADD CONSTRAINT fk_basetable
3. FOREIGN KEY (refid)
4. REFERENCES basetable (id)
5. ON UPDATE CASCADE;

Hierbei sorgt das RDBMS und im speziellen die "ON UPDATE CASCADE"-Klausel dafür, dass deine Fremdschlüsselbeziehung gültig bleibt und du dein Update auf der Basistabelle überhaupt durchführen darfst, da das RDBMS den Wert auf den neuen Wert setzt (in allen abhängigen Tabellen, die ein Fremdschlüssel-Constraint wie eben beschrieben besitzen).

Eine Alternative für manche Fälle wäre statttdessen die Klausel "ON UPDATE SET NULL". Dann würde das UPDATE-Statement auch durchlaufen, in der referenzierenden Tabelle würden aber die Datensätze, die ohne gültigen Verweis auf einen PK dastehen auf NULL gesetzt werden und könnten so nachträglich bearbeitet werden.

Markus

stimmt geht aus so. allerdings Primary Key neu zu vergeben ist trotzdem relativ schlecht.... Auch wenn es vielleicht mit diversen Kniffen geht. Aber ich glaube hierüber können 2 Köpfe auch 3 Meinungen bilden