Progettazione di database per voci dinamiche - Una riga o più righe?

Question

Ho cercato di progettare uno schema di database per un progetto secondario ma non sono stato in grado di produrre tutto ciò con cui mi trovo a mio agio. Sto usando ASP.Net con LINQ per il mio accesso ai dati:

Consentirò agli utenti di specificare fino a 10 "articoli". ognuno con 2 proprietà numeriche e 1 proprietà referenziale, il nome dell'elemento.

Se dovessi mettere questa voce in 1 riga, sarebbe facilmente uguale a circa 30+ colonne (minimo), ad es. item_1_name (rif) item_1_weight item_1_volume item_2_name ... etc ...

E non posso semplicemente trasformare queste colonne in tabelle referenziali poiché ogni proprietà può essenzialmente variare da 1 a 400+.

Ho anche pensato che se un utente decidesse di inserire solo 1 elemento nella sua voce, il metodo con cui creo l'oggetto per quei dati sarà statico come con LINQ dovrei controllare se le proprietà e quant'altro sono NULL e lavorare di conseguenza. Inoltre, se mai volessi aumentare il numero di elementi consentiti in una voce, sarebbe un mal di testa con cui lavorare.

L'altra opzione a cui ho pensato è semplicemente quella di creare una riga per ogni elemento e legarla con un ID voce. Quindi non avrei mai avuto voci nulle, ma la mia tabella sarebbe diventata astronomicamente profonda ma non molto ampia, dato che ci sarebbero solo circa 5 colonne dispari.

C'è qualcosa che sto trascurando nel mio design / c'è un modo molto migliore ed efficiente per farlo?

EDIT: quando dico che crescerà astronomicamente, intendo in questo senso: un utente può creare una voce e ogni voce avrà molto probabilmente un gruppo di elementi. Quindi supponiamo che effettuino 1 ingresso al giorno nel sito, potrebbero avere 3 gruppi di articoli, con il numero massimo di articoli (10), che equivarrebbe a 30 articoli per quell'unica voce. Inserisci una voce ogni giorno per una settimana a quel ritmo e potresti avere 210 righe per quel singolo utente.

Answer 1

Consiglierei quest'ultimo disegno che menzioni, crea una tabella dipendente con cinque colonne:

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

Mostro una tabella num_items sopra, che contiene i numeri da 1 a 10 se vuoi limitare al massimo gli utenti a 10 elementi:

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

I vantaggi di questo design sono che COUNT () è facile quanti elementi ha un determinato utente, è facile calcolare cose come MIN () e MAX () per una determinata proprietà, è possibile applicare una chiave esterna per la proprietà referenziale, ecc.

Alcuni database hanno una funzione per dichiarare la seconda parte di una chiave primaria composta ( item_id in questo caso) come auto-incremento, quindi se specifichi il valore per entity_id ma ometti item_id ottiene automaticamente il prossimo valore inutilizzato (ma non riempie gli spazi vuoti se ne elimini uno). Non dichiari quale marca di database stai usando, quindi ti lascerò a te per capire questa funzione.

modifica: Come afferma Tony Andrews nella sua risposta, il numero di righe non è un problema. Non dichiari quale marca di database intendi utilizzare, ma a meno che tu non scelga un prodotto particolarmente debole come MS Access, puoi fare affidamento sul database per elaborare facilmente milioni di righe. Se scegli bene gli indici e scrivi query che utilizzano tali indici, l'efficienza non dovrebbe essere un problema.

Answer 2

usa una singola tabella di elementi:

userId, itemIndex, isReference, numericValue, referenceValue

in questo modo il valore per item_3_name per l'utente 999 si traduce in

999,3, vero, null, il valore

Dovrai imporre tu stesso alcuni vincoli, s.a. il numero massimo di articoli per utente, ecc.

Answer 3

La corretta progettazione del database consisterebbe nel memorizzare ciascun utente / elemento in una riga separata. Sarà molto più facile lavorare con e rimuoverà la restrizione arbitraria di 10 articoli. Non direi che crescerà "astronomicamente profondo", ci saranno circa 10 x (n. Di utenti) righe.