Hilfe bei Datebankdesign
Hallo Leute,
da ich im Moment eine kleine Denkblockade habe, wende ich mich an euch
Ich möchte eine kleine Benutzerverwaltung für eine PHP Seite erstellen. Hierbei soll dann auch aufgezeichnet werden, wer wann wie was wo weshalb warum macht ;)
Dabei geht es um folgende Tabellen:
Ich möchte, das unter GeändertVon und ErstelltVon jeweils der User steht (also die BNr), der den anderen User erstellt oder bearbeitet hat. Aber ich hab gerade keinen Plan wie ich das hinbekomme.. Ich habs gefühl ich bräuchte noch eine Tabelle zwischen benutzer und überwachung..
Kann mir da wer unter die Arme greifen?
Danke
da ich im Moment eine kleine Denkblockade habe, wende ich mich an euch
Ich möchte eine kleine Benutzerverwaltung für eine PHP Seite erstellen. Hierbei soll dann auch aufgezeichnet werden, wer wann wie was wo weshalb warum macht ;)
Dabei geht es um folgende Tabellen:
create table gruppen (
GNr int unsigned auto_increment not null primary key,
GName varchar(20)
);
create table benutzer (
BNr int unsigned auto_increment not null primary key,
BName varchar(20) not null,
Passwort varchar(256) not null,
Gruppe int unsigned not null,
foreign key (Gruppe)
references gruppen(GNr)
);
create table überwachung(
UNr int unsigned auto_increment not null primary key,
LetzerLogin datetime,
LetzteAktio datetime,
Erstellt datetime not null,
ErstelltVon int unsigned not null,
Geändert datetime,
GeändertVon int unsigned,
foreign key (ErstelltVon)
references benutzer (BNr),
foreign key (GeändertVon)
references benutzer (BNr)
);
Ich möchte, das unter GeändertVon und ErstelltVon jeweils der User steht (also die BNr), der den anderen User erstellt oder bearbeitet hat. Aber ich hab gerade keinen Plan wie ich das hinbekomme.. Ich habs gefühl ich bräuchte noch eine Tabelle zwischen benutzer und überwachung..
Kann mir da wer unter die Arme greifen?
Danke
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 243370
Url: https://administrator.de/contentid/243370
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
GeändertVon braucht noch ein "not null" sonst klappt das mit dem ForeignKey nicht.
Grundsätzlich würde ich das anders ausfbauen.
eher so
lg,
Slainte
GeändertVon braucht noch ein "not null" sonst klappt das mit dem ForeignKey nicht.
Grundsätzlich würde ich das anders ausfbauen.
eher so
...
UNr int unsigned auto_increment not null primary key,
Zeitstempel datetime,
Aktion varchar(512),
DurchgefuehrtVon int unsinged not null,
DurchgefuehrtAn int unsinged not null,
foreign key (DurchgefuehrtVon) references benutzer (BNr),
foreign key (DurchgefuehrtAn) references benutzer (BNr)
lg,
Slainte
Moin SlaintheMath,
Das ist so nicht ganz richtig.
Das Feld GeändertVon kann durchaus NULLABLE sein - und der Inhalt darf dann auch bei gesetztem FK-Constraint entweder NULL oder ben ein gültiger Wert aus der referenzierten Parent-Tabelle sein.
Die Constraint sollte dann auch "ON DELETE SET NULL" beinhalten, d.h. wenn der "GeändertVon"-User 4711 aus der Parent-Tabelle gelöscht wird, dann soll in der Child-Tabelle überall der "GeändertVon"-User 4711 auf NULL geändert werden.
Dazu muss aber das Feld NULLABLE sein.
Grüße
Biber
Zitat von @SlainteMhath:
GeändertVon braucht noch ein "not null" sonst klappt das mit dem ForeignKey nicht.
GeändertVon braucht noch ein "not null" sonst klappt das mit dem ForeignKey nicht.
Das ist so nicht ganz richtig.
Das Feld GeändertVon kann durchaus NULLABLE sein - und der Inhalt darf dann auch bei gesetztem FK-Constraint entweder NULL oder ben ein gültiger Wert aus der referenzierten Parent-Tabelle sein.
Die Constraint sollte dann auch "ON DELETE SET NULL" beinhalten, d.h. wenn der "GeändertVon"-User 4711 aus der Parent-Tabelle gelöscht wird, dann soll in der Child-Tabelle überall der "GeändertVon"-User 4711 auf NULL geändert werden.
Dazu muss aber das Feld NULLABLE sein.
Grüße
Biber
@Biber
Ja du hast natürlich Recht. Ich arbeite bei FK's aber sehr ungern mit CASCADE/ON DELETE SET NULL. Lieber lass ich das DBS einen Fehler schmeissen als das es mir mit der NULL-Kettensäge durch die DB fährt
@TheUntouchable
Wenns Du's wirklich so haben willst, brauchst du keine zusätzliche Tabelle. Beachte aber den Post von Biber.
Ja du hast natürlich Recht. Ich arbeite bei FK's aber sehr ungern mit CASCADE/ON DELETE SET NULL. Lieber lass ich das DBS einen Fehler schmeissen als das es mir mit der NULL-Kettensäge durch die DB fährt
@TheUntouchable
Wenns Du's wirklich so haben willst, brauchst du keine zusätzliche Tabelle. Beachte aber den Post von Biber.
Moin Slainthe,,
na ja, bei CASCADE gebe ich dir recht.
Aber bei SET NULL...
Gerade hier in diesem Fall wären die Alternativen
- (bei einem Standard ON DELETE RESTRICT) - der User 4711, der vor 2 Jahren Admin war und 50 andere "geändert" hat (z.B. Passwort-Reset) darf niemals nich gelöscht werden, auch wenn er schon seit der letzten Sonnenwendfeier in Walhalla frühstückt.
- (bei ON DELETE CASCADE) - der User 4711 wird aus o.a. Gründen gelöscht und alle 50 User, denen er beim Passwort-Reset gehölfen hat, folgen ihm in die grosse Trinkhalle.
Da wäre meine Präferenz doch ein ON DELETE SET NULL.
Grüße
Biber:
na ja, bei CASCADE gebe ich dir recht.
Aber bei SET NULL...
Gerade hier in diesem Fall wären die Alternativen
- (bei einem Standard ON DELETE RESTRICT) - der User 4711, der vor 2 Jahren Admin war und 50 andere "geändert" hat (z.B. Passwort-Reset) darf niemals nich gelöscht werden, auch wenn er schon seit der letzten Sonnenwendfeier in Walhalla frühstückt.
- (bei ON DELETE CASCADE) - der User 4711 wird aus o.a. Gründen gelöscht und alle 50 User, denen er beim Passwort-Reset gehölfen hat, folgen ihm in die grosse Trinkhalle.
Da wäre meine Präferenz doch ein ON DELETE SET NULL.
Grüße
Biber: