Wenn Sie jemals Planen Sie, nach bestimmten Attributen zu suchen, ist es eine schlechte Idee, sie in einer einzelnen Spalte zu serialisieren, da Sie Funktionen pro Zeile verwenden müssen, um die Informationen herauszubekommen – dies lässt sich selten gut skalieren.
Ich würde mich für deine zweite Wahl entscheiden. Haben Sie eine Liste von Attributen in einer Attributtabelle, die Objekte in ihrer eigenen Tabelle und eine Viele-zu-Viele-Beziehungstabelle namens Objektattribute.
Zum Beispiel:
objects:
object_id integer
object_name varchar(20)
primary key (object_id)
attributes:
attr_id integer
attr_name varchar(20)
primary key (attr_id)
object_attributes:
object_id integer references (objects.object_id)
attr_id integer references (attributes.attr_id)
oa_value varchar(20)
primary key (object_id,attr_id)
Ihre Besorgnis über die Leistung wird zur Kenntnis genommen, aber meiner Erfahrung nach ist es immer teurer, eine Spalte zu teilen, als mehrere Spalten zu kombinieren. Wenn sich herausstellt, dass es Performance-Probleme gibt, ist es vollkommen akzeptabel, 3NF aus Performance-Gründen zu unterbrechen.
In diesem Fall würde ich es auf die gleiche Weise speichern, aber auch eine Spalte mit den rohen serialisierten Daten haben. Vorausgesetzt, Sie verwenden Insert/Update-Trigger, um die spaltenorientierten und kombinierten Daten synchron zu halten, werden Sie keine Probleme haben. Aber Sie sollten sich darüber keine Gedanken machen, bis ein tatsächliches Problem auftaucht.
Durch die Verwendung dieser Trigger minimieren Sie den Arbeitsaufwand auf nur wenn sich die Daten ändern. Indem Sie versuchen, Unterspalteninformationen zu extrahieren, leisten Sie unnötige Arbeit an allen auswählen.
