Sto cercando di creare una semplice lista di cose da fare con PHP, MySQL, Jquery templating e JSON ... Tuttavia, il mio schema sembra complicare le cose in JSON.
Qual è il modo migliore per farlo?
o
C'è uno scherzo che ho ascoltato da un po 'di tempo:
Q How does a BASIC coder count to 10?
A 1,2,3,4,5,6,7,8,9,10Q How does a C coder count to 10?
A 0,1,2,3,4,5,6,7,8,9Q How does a DBA count to 10?
A 0,1,many
La verità dietro questo scherzo è che una volta che hai due (o più) della stessa cosa in una struttura di database (colonne o tabelle), stai sbagliando.
Uno schema simile a:
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
È sbagliato perché dove inserirai un terzo numero di telefono se qualcuno lo ha?
Lo stesso vale per i tavoli stessi. È anche una brutta cosa modificare lo schema in fase di esecuzione, che la "nuova tabella per ogni lista" sembra implicare. (Related: MVC4: Come creare un modello in fase di esecuzione? )
E quindi, la soluzione è creare un elenco di cose da fare che comprende due tabelle. Ci sono due cose che hai: liste e articoli.
Quindi, creiamo una struttura tabella che rifletta questo:
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
L'elenco ha un id (la chiave primaria per la lista) 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 per supportarlo. Completato, 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 è quella che viene opportunamente normalizzata (o rendendosi conto dei compromessi che hai fatto perché non è normalizzata), avrai molti mal di testa più tardi.
Ora, tutto ciò riguarda la scrittura di questo come un database relazionale. Ma questo non è l'unico tipo di database là fuori. Se consideri che un elenco è un documento , i database in stile nosql possono anche offrire un approccio che non è sbagliato.
Anche se non ho intenzione di approfondire troppo, ci sono numerosi tutorial là fuori per le liste di cose da fare nel divano. Uno di questi che ha prodotto una ricerca è Una semplice applicazione Elenco di attività in CouchDB . Un altro si presenta nel wiki di couchdb: Schema proposto per elenchi di cose da fare .
Nell'approccio appropriato per un divano, ogni lista è un documento JSON memorizzato nel database. Dovresti semplicemente mettere la lista in un oggetto JSON e metterla nel database. E poi hai letto dal database.
Il JSON potrebbe essere simile a:
[
{"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}
]
(da creazione di una lista della spesa con un file json su Stack Overflow).
O qualcosa che si avvicina a questo. Ci sono altri documenti che mantengono quel divano come parte del documento.
Il problema è che non è il modo sbagliato di avvicinarsi e un elenco di cose da fare in un database di documenti può essere perfettamente adatto a quello che stai cercando di fare con meno spese generali di concetto per come per farlo.
L'opzione 2 è un'impostazione master / dettagli tradizionale. Questo è probabilmente quello che vuoi qui. Metti l'id lista nella tabella degli articoli e unisciti a quello. Lo schema non dovrebbe influire sul JSON. La tua query potrebbe essere simile a:
select lists.name as list_name, items.name as item_name
from items
join lists on (lists.id = items.list_id)
Non cercherò di legare la tua rappresentazione dell'interfaccia utente o la trasmissione di dati all'interfaccia utente direttamente al modo in cui intendi memorizzare i dati. Mantenendo i due separati e utilizzando una logica del middleware per sposare i due, è possibile modificare facilmente entrambi i lati senza influire in modo critico sull'altro.
Dal punto di vista dell'archiviazione dei dati, è probabile che si utilizzi l'opzione 2, che segue il tipico schema di dati normalizzato in cui le parti comuni vengono ridotte in considerazione nelle proprie tabelle per evitare ripetizioni e minimizzare il numero di database.
Dal punto di vista della vista, è sufficiente utilizzare una query del database per unire i dati pertinenti in un set di risultati e quindi iterare quel risultato e generare una risposta JSON applicabile alle esigenze dell'interfaccia utente. Quello che probabilmente vorresti fare è inserire i dati in JSON in modo che si adattino alle tue esigenze di interfaccia utente nel miglior modo possibile, eliminando spesso la necessità di ulteriore logica di scripting nelle tue pagine web.
Leggi altre domande sui tag database database-design