Tipo di cella dinamica della tabella SQL

Question

Diciamo che ho un Product e a ProductType tavolo. Voglio una tabella in cui posso archiviare colonne speciali per ogni tipo di prodotto. Le colonne speciali (attributi) possono essere di qualsiasi tipo.

In questo momento abbiamo un tavolo per ProductType chiamato Product_%ProductTypeId% Qual è una soluzione che non mi piace davvero - nessun suggerimento?

La mia idea era di avere un tavolo ProductTypeColumns con cols:

Id | ProductTypeId | ColumnName | Value  | ColumnType

Quello che non mi piace è che sto perdendo sicurezza, colonna Value Sarebbe un tipo di stringa che significherebbe che devo sempre convertire da e verso.

Inoltre questa tabella verrà utilizzata per generare report. Avere colonne "dinamiche" potrebbe essere un problema.

Answer 1

Questo è chiamato EAV.
Puoi trovare alcune domande su EAV e SQL Server qui su:

• EAV su SQL Server
• Prestazioni di grandi sistemi Schema EAV/Open su SQL Server

È un argomento in cui molte persone diverse avranno opinioni diverse.
Alcuni diranno che dovresti restare Product_%ProductTypeId% tavoli e alcuni diranno che il tuo ProductTypeColumns Il tavolo è il modo migliore.

Fondamentalmente, sono nel ProductTypeColumns campo.
Stiamo usando qualcosa di simile anche al lavoro:
La nostra tabella contiene attributi per articoli d'ordine (oltre un milione di articoli d'ordine e oltre 250 milioni di attributi) e lo stiamo usando da quasi dieci anni.
Svantaggi: nessun tipo di sicurezza (come hai già accennato) e La query può essere un po 'complicata.

Ma per noi, è l'unico modo possibile perché abbiamo oltre 1000 attributi, oltre 100 prodotti e ogni prodotto può avere attributi da 100 a 300. Con dimensioni come queste, una tabella degli attributi è l'unico modo possibile.
Ma probabilmente non è la soluzione migliore per tutti e non so se è la soluzione migliore per te.

Se il tuo numero di prodotti e attributi speciali non è così grande, forse puoi cavartela con il tuo primo suggerimento (Product_%ProductTypeId% tabelle).
Sarebbe sicuramente più facile da interrogare, ma forse non è un'opzione se ci sono troppe possibili combinazioni di prodotti e attributi.

Come spesso dipende.

Answer 2

Che ne dici di gerarchia di categoria (aka. "Ereditarietà", "sottotipo", "sottoclasse")?

Andavo personalmente con una soluzione di coppia Nome/Value (descritta nella tua domanda) solo se le colonne sono non predeterminato.

Se conosci tutte le colonne in anticipo e è improbabile che cambino, implementando una gerarchia di categoria, Sebbene non senza complicazioni, preserverebbe la sicurezza del tipo e consentirebbe una migliore applicazione dell'integrità dichiarativa da parte del DBMS (ad esempio, potresti avere un prodotto specifico del prodotto una chiave univoca, straniera o un vincolo di controllo).