Normalisierung angebracht?

[Auge]

Hallo

Der Thread ist zwar schon relativ alt und gelöst, möchte aber trotzdem noch meinen Senf zur Struktur abgeben:

Tabelle: Beitraege
id | text  | user_id | name | email           | email_notify
1 | bla   |       0 | Ulf  | [e-mail] |            1
2 | blubb |       1 |      |                 |            1

Tabelle: Benutzer
id | name | email
1 | Alf  | [e-mail]

Ich find die Struktur unpassend, da sie relativ viel Redundanz beinhaltet.

Kuzer historischer Ausflug: Die Struktur der hier Beitraege genannten Tabelle stammt aus einer Zeit, als in diesem Skript registrierte Benutzer noch nicht vorgesehen waren. Als der damalige Entwickler sich entschied, diese Funktion bereitzustellen, fügte er das Feld user_id und die Tabelle für die Daten der registrierten Benutzer hinzu. Auf diese Art blieben bei einem Update des Skripts die bisherigen Einträge unangetastet.

Die Struktur blieb bis heute so, wie sie damals festgelegt wurde. Ich habe auch schon darüber nachgedacht, das zu entzerren, habe dafür aber noch keine vernünftige Lösung gefunden.

Wenn sowieso ein Feld für die User-ID existiert, sollte man dann nicht auch alle User-Informationen in die Benutzer-Tabelle stopfen und zwar nur dort?

Grundsätzlich richtig, aber ...

Die Unterscheidung zwischen registriertem und nicht-registriertem Benutzer könnte man in ein eigenes Feld in der Benutzer-Tabelle auslagern, ...

... im Falle eines wiederholt postenden nicht registrierten Nutzers heißt das, dass das Skript ihn an einem weiteren Datum (z.B. einem Cookie oder der Emailadresse [1]) wiedererkennen können muss. Wenn jemand mehrfach, aber mit großem zeitlichen Abstand postet, ist es durchaus möglich, dass der Keks abgelaufen ist oder die Emailadresse gewechselt wurde. Dann passiert, dass er mehrfach in der Tabelle für die Benutzerdaten auftaucht. Das würde diese Tabelle erstens unnötig aufblähen. Zweitens kann man davon ausgehen, dass es mehrere nicht registrierte Benutzer gibt, die unter dem gleichen Namen posten. Wie soll das Skript diese dann (für eine eventuelle spätere Zuordnung der Postings zu einem nun registrierten Benutzer) unterscheiden bzw. die Postings mehrerer eingetragener Benutzer, die zum selben Poster gehören, zusammenfassen?

... email_notify auch (wenn es nur global sein soll), wenn man einen globalen Standardwert dafür haben will, aber auch für jeden Beitrag entscheiden könen möchte halt in beiden.

Persönliche Meinung: eine globale Einstellung zur Benachrichtigung bei jedem neuen Eintrag ist mMn falsch. Bei einer Instanz mit viel Betrieb kann das in spamähnliche Zustände ausarten. Dafür ist mMn ein RSS-Feed besser geeignet und der ist vorhanden.

Im Skript ist die Benachrichtigung per Email tatsächlich folgendermaßen geregelt. Klassisch ist die Einstellung, dass man sich über Antworten auf das eigene Posting benachrichtigen lassen kann [2]. Zudem kann man einzelne Threads abonnieren, wobei dann bei einer Antwort auf irgendeinen Beitrag im Thread eine Benachrichtigung geschickt wird.

Also Beitraege wäre dann
id, text, user_id (, email_notify)

und Benutzer
id, registered, name, email (, email_notify)

Vorteil: Einfach gehaltenes Query, dadurch besser wartbar.

Eventuell weiterer Vorteil: Falls sich ein nicht-registrierter Benutzer immer unter gleichen Namen und gleicher E-Mailadresse meldet und sich dann doch zur Registrierung entscheidet, wäre eine Zuordnung alter Beiträge möglich.

Meine Bedenken dazu stehen ja oben. Die Idee ist grundsätzlich nicht schlecht, ich wüsste aber keinen sicheren Weg das umzusetzen.

Nachteil: Wenn der Tabelle Benutzer weitere Informationen für registrierte Benutzer hinzukommen, hat man für unregistrierte Benutzer entweder ein haufen NULL-Felder, oder aber man muss eine extra Tabelle für Benutzerinformationen erzeugen.

An der Stelle wäre wohl die weitere Teilung der Tabellen der bessere Weg.

(Hierbei interessiert mich auch die Meinung der Gurus)

[1] Momantan ist es so, dass die Angabe einer Emailadresse nur dann nötig ist, wenn man über Antworten benachrichtigt werden will.
[2] so, wie hier in der Tabellenstruktur abzulesen

Tschö, Auge