2013-03-13 5 views
5

Il database memorizza diversi tipi di oggetto per progetti ingegneristici: motori, cavi, pompe, sensori ecc.Vorrei memorizzare molti tipi di oggetto in un database SQL. Devo avere una tabella diversa per ogni tipo di oggetto?

Stiamo discutendo se avere una tabella diversa per ogni tipo di oggetto? (Mucchi di tabelle, un dolore quando vogliamo aggiungere un nuovo tipo di oggetto - cosa che succederebbe ogni tanto ...)

Oppure, come facciamo attualmente, dovremmo avere una tabella che memorizza i tipi di oggetto (ID, nome) e un'altra tabella che memorizza i possibili attributi per ogni tipo di oggetto e un'altra tabella che memorizza i valori di ciascun attributo per ciascun tipo di attributo? (Un vero PITA, ma flessibile.)

Qualcuno ha fatto qualcosa di simile? Punti da considerare? Implementazione?

+3

Per me quest'ultimo sembra un po 'come se si stesse cercando di creare il proprio database NoSQL utilizzando un database SQL come storage. –

+3

Suona come EAV rispetto a Tabella per tipo. Vedi [qui] (http://stackoverflow.com/questions/4066463/should-i-use-eav-model?lq=1) e [qui] (http://stackoverflow.com/questions/870808/entity- valore attributo-database-vs-rigoroso-modello-relazionale-ecommerce-domanda) –

+1

possibile duplicato di [tabella prodotto, molti tipi di prodotto, ogni prodotto ha molti parametri] (http://stackoverflow.com/questions/695752/ tabella prodotto-molti-tipi-di-prodotto-ogni-prodotto-ha-molti-parametri) –

risposta

6

Se riesci a mettere le mani su una copia di Patterns of Enterprise Application Architecture (Fowler) dai un'occhiata allo Object-Relational Structural Patterns; ci sono pro e contro per ogni approccio e la risposta sarà diversa a seconda del contesto del tuo particolare progetto.

In particolare:

Single Table Inheritance

Class Table Inheritance

Concrete Table Inheritance

Serialized LOB (e se si considera questo modello considera anche utilizzando un archivio dati NoSQL, invece di un RDBMS)

Il più grande la domanda a cui dovrai rispondere è w se un database relazionale è l'archivio dati giusto per i tuoi dati. Stai solo cercando un posto dove archiviare i dati? Utilizzerai i dati di oggetti diversi in relazione l'uno con l'altro? Potrebbe essere sufficiente utilizzare un grande framework di serializzazione (come Kryo) in un Serialized LOB e memorizzare i metadati necessari per la ricerca o l'associazione di relazioni in colonne standard.

+2

Come sempre, una chiara comprensione dei requisiti aziendali è un prerequisito necessario per fare una scelta tecnologica ragionevole. –