C'è una battuta che ho sentito poco tempo fa:
D In che modo un programmatore BASIC conta fino a 10?
A 1,2,3,4,5,6,7,8,9,10
D In che modo un codificatore C conta fino a 10?
A 0,1,2,3,4,5,6,7,8,9
D In che modo un DBA conta fino a 10?
A 0,1, molti
La verità dietro questa battuta è che una volta che hai due (o più) della stessa cosa in una struttura di database (colonne o tabelle), stai sbagliando.
Uno schema che assomiglia a:
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
È sbagliato perché dove inserirai un terzo numero di telefono se qualcuno lo possiede?
Lo stesso vale per le tabelle stesse. È anche una cosa negativa modificare lo schema in fase di esecuzione, che la "nuova tabella per ogni elenco" sembra implicare. (Correlato: MVC4: come creare un modello in fase di esecuzione? )
E quindi, la soluzione è creare un elenco di cose da fare composto da due tabelle. Ci sono due cose che hai: elenchi ed elementi.
Quindi, facciamo una struttura di tabella che rifletta questo:
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
L'elenco ha un ID (la chiave primaria per l'elenco) e un nome. L'attività ha un id (la chiave primaria) un listid (una chiave esterna) e la descrizione dell'attività. La chiave esterna si riferisce alla chiave primaria di un'altra tabella.
Sottolineerò che questo non inizia a comprendere tutte le possibilità in vari requisiti per il software e la struttura della tabella di supportarlo. Completati, data di scadenza, ripetizione, ecc ... sono tutte strutture aggiuntive che probabilmente dovranno essere prese in considerazione durante la progettazione della tabella. Detto questo, se la struttura della tabella non è adeguatamente normalizzata (o realizzando i compromessi che hai fatto perché non è normalizzata), avrai molti mal di testa in seguito.
Ora, tutto ciò che riguarda la scrittura di questo come un database relazionale. Ma questo non è l'unico tipo di database là fuori. Se consideri un elenco come un documento, anche i database nosql in stile documento possono offrire un approccio che non è sbagliato.
Anche se non approfondirò troppo, ci sono numerosi tutorial là fuori per le liste di cose da fare sul divano. Uno di questi che è venuto fuori con una ricerca è una semplice applicazione Elenco attività in CouchDB . Un altro si presenta nella wiki di couchdb: Schema proposto per le liste di cose da fare .
Nell'approccio appropriato per un divano, ogni elenco è un documento JSON memorizzato nel database. Dovresti semplicemente inserire l'elenco in un oggetto JSON e inserirlo nel database. E poi leggi dal database.
Il JSON potrebbe apparire come:
[
{"task":"get milk","who":"Scott","dueDate":"2013-05-19","done":false},
{"task":"get broccoli","who":"Elisabeth","dueDate":"2013-05-21","done":false},
{"task":"get garlic","who":"Trish","dueDate":"2013-05-30","done":false},
{"task":"get eggs","who":"Josh","dueDate":"2013-05-15","done":true}
]
(a partire dal creazione di una lista della spesa con un file json su Stack Overflow).
O qualcosa di simile a quello. C'è qualche altra registrazione che quel divano ha come parte del documento.
Il fatto è che non è il modo sbagliato di avvicinarsi e un elenco di cose da fare in un database di documenti può essere perfettamente adatto a ciò che si sta tentando di fare con un sovraccarico di concetti per come farlo.