Jeśli kiedykolwiek planować wyszukiwanie określonych atrybutów, kiepskim pomysłem jest ich serializacja w jednej kolumnie, ponieważ będziesz musiał użyć funkcji na wiersz, aby uzyskać informacje - rzadko jest to dobrze skalowane.
Wybrałbym twój drugi wybór. Miej listę atrybutów w tabeli atrybutów, obiekty we własnej tabeli i tabelę relacji wiele-do-wielu zwaną atrybutami obiektów.
Na przykład:
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)
Zauważono Twoją troskę o wydajność, ale z mojego doświadczenia wynika, że dzielenie kolumny jest zawsze bardziej kosztowne niż łączenie wielu kolumn. Jeśli okaże się, że występują problemy z wydajnością, złamanie 3NF jest całkowicie dopuszczalne ze względu na wydajność.
W takim przypadku zapisałbym go w ten sam sposób, ale miałbym również kolumnę z surowymi danymi serializowanymi. Pod warunkiem, że używasz wyzwalaczy wstawiania/aktualizacji, aby zachować synchronizację danych kolumnowych i połączonych, nie będziesz mieć żadnych problemów. Ale nie powinieneś się tym martwić, dopóki nie pojawi się rzeczywisty problem.
Używając tych wyzwalaczy, minimalizujesz nakład pracy tylko kiedy dane się zmienią. Próbując wyodrębnić informacje z podkolumn, wykonujesz niepotrzebną pracę nad każdym wybierz.
