Buona progettazione del database, numero variabile di attributi

Question

Sto provando a creare un database che contiene un elenco di apparecchiature. Tutte le apparecchiature avranno determinati attributi comuni (come produttore, numero di modello, numero di serie, ecc.), Quindi ci sono altri attributi specifici per un determinato componente (ad esempio, un modem avrà un accesso #, mentre un pannello solare avrà una capacità di uscita). Non sono sicuro di come rappresentare questi attributi mutevoli con buoni principi di progettazione del database, ho provato a cercare sul web, ma non sono del tutto sicuro di cosa cercare.

mi è venuta in mente le seguenti soluzioni possibili ei miei pensieri iniziali su di loro:

1. Avere un grande tavolo con tutti gli attributi possibili e appena messo nulla in cui non è applicabile. Ovviamente questo ha alcuni difetti.

2. Avere una tabella separata per ciascun tipo di apparecchiatura. Sembra che potrebbe essere un incubo da usare, se voglio stampare un elenco di tutte le attrezzature, come faccio a sapere quali tabelle cercare?

3. Avere una tabella con gli attributi comuni e altre tabelle per ogni tipo di apparecchiatura a cui si accede con una chiave esterna per memorizzare gli attributi aggiuntivi. Probabilmente potrei farlo funzionare, ma sarebbe ingombrante e non mi sembra una buona soluzione.

4. Un modello di tipo valore attributo di entità. Semplicemente non mi sembra una buona idea per quello che voglio fare.

Non ho molta esperienza con i database così sto imparando come vado qui, tutti i link relativi a questo problema o "deve leggere" articoli sul progettazione di database sarebbe apprezzato. Grazie!

MODIFICA: Prima di tutto, ho scoperto che avevo bisogno di Google "Mapping ereditarietà", che potrebbe aiutare chiunque abbia una domanda simile. Per risolvere il problema ho finito per utilizzare un ibrido di # 2 e # 3. In realtà è piuttosto semplice, funziona bene e risolve il problema dell'aggiunta di ulteriori tipi di apparecchiature senza la complessità dell'EAV. Grazie per tutti i commenti e suggerimenti!

Answer 1

opzioni 1, 2, e 3 condividono un difetto molto grave: è necessario modificare lo schema della tabella sottostante quando qualcuno sogna un nuovo attributo. Nel caso dell'opzione 1, il problema è aggravato dalla possibilità che venga introdotto un nuovo tipo di attrezzatura. Quanto ne sei sicuro che il set di attributi è fissato per tutto il tempo?Quanto sarai contento di prendere delle interruzioni o dire al cliente che no, non puoi avere un nuovo attributo?

Se è molto probabile eseguire query su attributi comuni, è possibile provare un ibrido di 3 e 4, con un trattino di 2 gettato in divisione su tipo di attributo piuttosto che tipo di apparecchiatura, che sembra molto più volatile. L'opzione 4, se capisco correttamente, è una versione normale della forma dell'opzione 1 che risolve tutti i suoi problemi inerenti (sparseness e fragilità).

INVENTORY(id*, model, manufacturer, serial) 
ATTRIBUTE(id*, name, type, description) 
INVENTORY_FACT_STRING(inv_id*, attr_id*, value) 
INVENTORY_FACT_NUMBER(inv_id*, attr_id*, value) 
INVENTORY_FACT_LIST_STRING(inv_id*, attr_id*, ordinal*, value) 

ecc

Answer 2

È difficile risolvere qualsiasi database SQL. Non c'è una grande risposta per MySQL.

1) Funziona ed è possibile aggiungere alcune viste per tipi di apparecchiature importanti. Riduce il numero di join e consente query e indici su ciascun campo.

2) È possibile utilizzare una query unione tutti in vista. PostgreSQL e Informix hanno ereditarietà di tabelle.

3) Questa è spesso una scelta di implementazione. Di nuovo, puoi usare le viste per i join.

4) PostgreSQL, Informix, Oracle, IBM DB2 e MS SQL Server hanno un supporto tipo di dati XML per implementare le coppie di valori.

Al livello più alto si potrebbe sviluppare un modello di meta delle apparecchiature in XML. Quindi è possibile utilizzare questo modello per generare query SQL dello schema e codice CRUD.

Answer 3

Penso che avete dovuto affrontare una normalizzazione del database regolare. Hai bisogno di tavoli come:

Items -> Id, Name, Model, Brand Id 
Brands -> Id, Name 
Attribute Names -> id, name 
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description 

Nel caso in cui non v'è più di un'Attribué, lista poi in tabelle di attributi e di associarsi con prodotto ID, ecc Prova a venire con forma normalizzata 3 °

Database Normalization

Answer 4

Le alternative 1, 2 e 3 sono delineate da Martin Fowler in uno dei suoi libri e sul suo sito web.

Single Table Inheritance (option 1)

Concrete Table Inheritance (option 2, sort of)

Class Table inheritance (option 3)

La mia preferenza è l'opzione 3. Ognuno ha il suo posto nello schema generale delle cose.

EAV accetta l'aggiunta di nuovi attributi al volo molto bene. Ma quando arriva il momento di trasformare i dati in informazioni utili, un database EAV può essere un incubo.

Ho una risposta più lunga, che posterò su richiesta.