Se mai pianificare la ricerca di attributi specifici, è una cattiva idea serializzarli in un'unica colonna, dal momento che dovrai utilizzare le funzioni per riga per ottenere le informazioni, che raramente si adattano bene.
Io opterei per la tua seconda scelta. Avere un elenco di attributi in una tabella degli attributi, gli oggetti nella loro tabella e una tabella di relazione molti-a-molti chiamata attributi degli oggetti.
Ad esempio:
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)
La tua preoccupazione per le prestazioni è nota ma, secondo la mia esperienza, è sempre più costoso dividere una colonna che combinare più colonne. Se si scopre che ci sono problemi di prestazioni, è perfettamente accettabile rompere 3NF per motivi di prestazioni.
In tal caso lo memorizzerei allo stesso modo ma avrei anche una colonna con i dati serializzati grezzi. A condizione che utilizzi i trigger di inserimento/aggiornamento per mantenere sincronizzati i dati colonnari e combinati, non avrai problemi. Ma non dovresti preoccuparti di questo fino a quando non emerge un problema reale.
Utilizzando questi attivatori, riduci al minimo il lavoro richiesto a solo quando i dati cambiano. Tentando di estrarre informazioni dalle sottocolonne, esegui lavori non necessari su ogni seleziona.
