unnötige Normalisierung

Question

Mein Freund und ich bauen gerade eine Website und haben eine große Meinungsverschiedenheit. Der Kern der Website ist eine Datenbank mit Kommentaren über "Menschen". Im Grunde können die Leute einen Kommentar abgeben und die Person angeben, um die es in dem Kommentar geht. Dann können die Betrachter die Datenbank nach Wörtern durchsuchen, die im Kommentar oder in Teilen des Namens der Person vorkommen. Die Datenbank ist vollständig nutzergeneriert. Wenn jemand zum Beispiel einen Kommentar zu einer falsch geschriebenen Version des Namens einer Person abgeben möchte, kann er das tun, und das ist auch in Ordnung. Es kann also sein, dass es mehrere Schreibweisen verschiedener Personen gibt, die in verschiedenen Einträgen aufgeführt sind (manche mit Mittelnamen, manche mit Spitznamen, manche falsch geschrieben usw.), aber das ist alles in Ordnung. Es ist uns egal, ob die Leute Kommentare über beliebige Personen oder imaginäre Personen abgeben.

Wie auch immer, es geht darum, wie wir die Datenbank strukturieren. Im Moment ist es nur eine Tabelle mit der Kommentar-ID als Primärschlüssel, und dann gibt es ein Feld für die "Person", über die der Kommentar ist:

Kommentar ID - Kommentar - Person

1 - "Er ist seltsam" - John Smith

2 - "stinkendes Mädchen" - Jenny

3 - "schwul" - John Smith

4 - "schuldet mir 20 Dollar" - Jennyyyyyyyyy

Alles funktioniert einwandfrei. Mit Hilfe der Datenbank kann ich Seiten erstellen, die alle "Kommentare" zu einer bestimmten "Person" auflisten. Er ist jedoch besessen davon, dass die Datenbank nicht normalisiert ist. Ich habe mich über Normalisierung informiert und herausgefunden, dass er sich geirrt hat. Die Tabelle IST derzeit normalisiert, weil die Kommentar-ID eindeutig ist und den "Kommentar" und die "Person" vorgibt. Jetzt besteht er darauf, dass "Person" eine EIGENE Tabelle haben sollte, weil sie ein "Ding" ist. Ich glaube nicht, dass das notwendig ist, denn obwohl die "Person" der größere Container ist (eine "Person" kann viele "Kommentare" über sie haben), scheint die Datenbank gut zu funktionieren, wenn die "Person" ein Attribut der Kommentar-ID ist. Ich verwende verschiedene PHP-Aufrufe für verschiedene SQL-Auswahlen, um die Ausgabe und die Art und Weise, wie der Benutzer suchen und Ergebnisse sehen kann, komplizierter erscheinen zu lassen, aber in Wirklichkeit ist der Aufbau recht einfach. Ich lasse die Benutzer nun Kommentare mit Daumen hoch und Daumen runter bewerten und führe eine "Punktzahl" als weiteres Feld in derselben Tabelle.

Meiner Meinung nach besteht derzeit keine Notwendigkeit für eine separate Tabelle für eindeutige "Personen"-Einträge, da die "Personen" keine eigene "Punktzahl" oder andere eigene Attribute haben. Das tun nur die Kommentare. Mein Freund besteht darauf, dass dies aus Effizienzgründen notwendig ist. Schließlich sagte ich: "OK, wenn du willst, dass ich eine separate Tabelle anlege und 'Person' ein eigenes Feld ist, was wäre dann das zweite Feld? Denn wenn eine Tabelle nur eine einzige Spalte hat, erscheint sie sinnlos. Ich stimme zu, dass wir später vielleicht eine eigene Tabelle für 'Person' brauchen, aber das können wir dann regeln. Er sagte dann, dass Zeichenketten keine Primärschlüssel sein können und dass wir die "Personen" in der aktuellen Tabelle in Zahlen umwandeln würden, und die Zahlen würden der Primärschlüssel in der neuen Tabelle "Person" sein. Dies erscheint mir unnötig und würde die Lesbarkeit der aktuellen Tabelle erschweren. Er ist auch der Meinung, dass es unmöglich sein wird, die zweite Tabelle später zu erstellen, und dass wir jetzt schon vorhersehen müssen, dass wir sie später für etwas brauchen könnten.

Wer hat Recht?

Answer 1

Das Erstellen einer neuen Tabelle für die Person und die Verwendung des Schlüssels dieser Tabelle anstelle des Attributs "Person" hat nichts mit Normalisierung zu tun. Es mag aus anderen Gründen eine gute Idee sein, aber dadurch wird die Datenbank nicht "normalisierter" als wenn man es nicht tut. Sie haben also Recht: Was die Normalisierung betrifft, ist die Erstellung einer weiteren Tabelle unnötig.

Answer 2

Meiner Meinung nach hat Ihr Freund Recht.

Man sollte in einer anderen Tabelle leben und versuchen, sich zu normalisieren. Übertreiben Sie es aber nicht.

Langfristig möchten Sie vielleicht mehr mit Ihrer Website machen, z.B. mehrere Dateien an eine Person anhängen (z.B. Bilder), dann werden Sie für die Normalisierung sehr dankbar sein.

Answer 3

Ich würde für Ihren Freund stimmen. Ich mag es, zu normalisieren und für die Zukunft zu planen, und selbst wenn Sie es nie brauchen, ist diese Normalisierung so einfach zu machen, dass sie buchstäblich keine Zeit kostet. Sie können eine Ansicht erstellen, die Sie abfragen, um Ihr SQL sauberer zu machen und die Notwendigkeit zu beseitigen, dass Sie die Tabellen selbst verbinden.

Answer 4

Wenn Sie bereits alle Ihre Möglichkeiten ausgeschöpft haben und keine Pläne zur Erweiterung Ihrer Möglichkeiten haben, sollten Sie es so lassen, wie es ist.

Wenn Sie vorhaben, noch mehr hinzuzufügen, z. B. dass Personen Konten haben können, halte ich es für sinnvoll, Ihre Daten in die Tabellen Person und Kommentare aufzuteilen. Das ist nicht schwer und macht die Erweiterung Ihrer Funktionalität einfacher.

Answer 5

Sie haben Recht.

Person kann generell eine Sache sein, aber nicht in Ihrem Modell. Wenn Sie die Leute dazu bringen wollten, die Person, von der sie sprechen, richtig zu identifizieren, wäre ein Person Tabelle notwendig wäre. Zum Beispiel, wenn sich die Kommentare nur auf bereits in der Datenbank registrierte Personen beziehen.

Aber hier sieht es so aus, als hätten Sie unstrukturierte Daten ohne Identität; und dass nichts/keiner daran interessiert ist, sicherzustellen, ob "jenny" und "jennyyy" tatsächlich dieselbe Person sind, ganz zu schweigen von "jenny doe" und "my cousin"...