DB parti di progettazione

Opzione 3 : (a volte)
L'opzione 3 è il "EAV" design. In teoria è bello perché i campi vengono estratti dalla struttura della tabella e diventano dati. Ma dà prestazioni terribili. Inoltre, non consente l'uso dell'indicizzazione corretta. E rende le query molto più complicate.

Userei l'EAV solo in circostanze speciali. Ho usato EAV per calcolare le parti ausiliarie necessarie per gli ordini e ha funzionato bene. Ma sii molto stanco di usarlo come design per i tuoi tavoli principali.

Opzione 2 : (mai?)
L'opzione 2 è un no no. E i campi condivisi? Hai intenzione di duplicare la struttura della tabella per ogni campo condiviso? Richiederebbe di includere i sindacati nei report dell'intero sistema.

Opzione 1 : (vincitore!)
L'opzione 1 potrebbe sembrare un po 'troppo semplice, ma probabilmente è la migliore scommessa per i tuoi tavoli principali. Tutte le parti utilizzano la stessa tabella principale per i campi condivisi in modo da evitare i sindacati nei report. Ha grandi prestazioni che consentono il corretto utilizzo dell'indicizzazione. Le query sono nello stile tradizionale e sono semplici.

Lo svantaggio dell'opzione 1 è che non puoi aggiungere campi dinamicamente. Ma lo vuoi davvero? Aggiungendo dinamicamente i campi si sta eseguendo la progettazione del database in fase di esecuzione.

Tenderei a non scegliere l'opzione # 3.

L'opzione n. 3 è l'impostazione della coppia nome-valore che viola la normalizzazione.

Idealmente, si tenta di avere un certo livello di normalizzazione del database. Impegnarsi per la completa normalizzazione e quindi denormalizzare se necessario quando viene identificato per problemi di personalizzazione o di prestazioni.

Considera la query "quali sono il nome e gli ID delle parti per tutti i fili di rame"

La struttura # 1 è

select
  name, parts.id
from
  wire, parts
where
  wire.material = 'copper'
  and wire.part_id = parts.id

La struttura # 2 è

select id, name from wire where material = 'copper'

La struttura # 3 è

select
  parts.name,
  parts.id,
from
  parts, part_types, part_values, value_types
where
  part_types.name = "wire"
  and parts.part_type_id = part_types.id
  and value_types.name = "material"
  and value_types.id = part_values.type_value_id
  and part_values.value = "copper"

Considera anche la complicazione degli inserimenti e delle eliminazioni dal sistema.

Qualche ulteriore lettura sul perché no # 3 - La maledizione della coppia valore nome

Vorrei iniziare con un modello di dati / oggetto che consente l'ereditarietà e quindi utilizzare una mappatura relazionale di oggetti . In questo modo ottieni una classe base Parts e sottoclassi come Wires , Contacts ecc. Ora, se si applica una strategia "mappa-ogni-classe-a-propria-tabella", si ottiene l'opzione 1, che è la soluzione più "normalizzata" e dovrebbe essere la strategia canonica se non hai più informazioni sulle query che ti aspetti.

L'opzione 2 è ciò che ottieni applicando un approccio "map-each-concrete-class-to-own-table". Questo può evitare "join" e può funzionare meglio per qualche tipo in caso di query (in particolare query per un solo "tipo di parte"), d'altra parte rende più complessa e più lenta la gestione generica con tutte le parti. Evita questo se non hai motivi particolari per questo.

L'opzione 3 è ciò di cui hai bisogno solo se desideri che l'utente modifichi il numero di tipi di parti in fase di esecuzione - se non ti aspetti tale requisito, l'opzione 3 sarà un esempio perfetto per le cose di over-engineering.

Con il database DB NOSQL (come MongoDB per esempio) avrai solo bisogno di un set chiamato "Parts". Ogni parte di quel set è il cosiddetto documento - registra con un set di campi variabile:

{
   "_id": ObjectId("4efa8d2b7d284dea1"),
   "partType": "wire",
   "length": 102.5,
   "diameter": 1.5,
   "material": "silver"
}, 
{
   "_id": ObjectId("4efa8d2b7d284sjsq23d"),
   "partType": "contact",
   "description": "something",
   "picture": Binary(...)
}, 

Penso che questa sia l'archiviazione di dati più naturale per l'attività che descrivi.

Assolutamente andare con l'opzione 1 ma con alcune semplici modifiche:

Parts      (id, part_type_id, name)
PartTypes  (id, name)
Wires      (id, part_id, part_type_id, lenght, diameter, material)
Contacts   (id, part_id, part_type_id, description, picture)

È quindi possibile utilizzare i vincoli CHECK e i valori DEFAULT per garantire che il part_type_id sia corretto e quindi è possibile partecipare sia a part_type_id che a part_id. Ciò evita di avere un join condizionale basato su una sola tabella, e se è necessario aggiungere un part_type_id ai fili (diciamo che stiamo suddividendo quella parte e aggiungendo un'altra tabella di attributi estesi) i vincoli di default e di controllo possono essere modificati.

L'opzione 3 è più generica e può ospitare più casi d'uso.

Se vai all'opzione 3 potresti aver bisogno di più join e query complesse per funzionalità semplici, nell'opzione 2 avresti bisogno di query complesse per funzionalità "grandi" come inventario e rapporti e potrebbe essere necessario utilizzare i sindacati per farlo.

Puoi sempre semplificare le tue query nelle opzioni 3 usando Views, se molto spesso hai bisogno solo del filo o del contatto, crea una vista per ognuna di esse. Puoi ottimizzarlo se diventa necessario.