Il y a une blague que j'ai entendue depuis un moment:
Q Comment un codeur BASIC compte-t-il jusqu'à 10?
A 1,2,3,4,5,6,7,8,9,10
Q Comment un codeur C compte-t-il jusqu'à 10?
A 0,1,2,3,4,5,6,7,8,9
Q Comment un DBA compte-t-il jusqu'à 10?
A 0,1, beaucoup
La vérité derrière cette blague est qu'une fois que vous avez deux (ou plus) de la même chose dans une structure de base de données (colonnes ou tables), vous vous trompez.
Un schéma qui ressemble à:
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
Est-ce faux, où allez-vous mettre un troisième numéro de téléphone si quelqu'un l'a?
La même chose s'applique aux tables elles-mêmes. C'est également une mauvaise chose de modifier le schéma au moment de l'exécution, ce que la "nouvelle table pour chaque liste" semble impliquer. (Connexes: MVC4: comment créer un modèle au moment de l'exécution? )
Et donc, la solution est de créer une liste de tâches composée de deux tables. Il y a deux choses que vous avez - des listes et des articles.
Donc, faisons une structure de table qui reflète ceci:
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
La liste a un identifiant (la clé primaire de la liste) et un nom. La tâche a un id (la clé primaire) un listid (une clé étrangère) et la description de la tâche. La clé étrangère renvoie à la clé primaire d'une autre table.
Je soulignerai que cela ne commence pas à englober toutes les possibilités dans diverses exigences pour le logiciel et la structure de la table pour le prendre en charge. Terminé, date d'échéance, répétition, etc ... ce sont toutes des structures supplémentaires qui devront probablement être prises en compte lors de la conception de la table. Cela dit, si la structure de la table n'est pas celle qui est normalisée de manière appropriée (ou réalisant les compromis que vous avez faits parce qu'elle n'est pas normalisée), vous aurez beaucoup de maux de tête plus tard.
Maintenant, tout ce qui concerne l'écriture de cette base de données relationnelle. Mais ce n'est pas le seul type de base de données. Si vous considérez une liste comme un document, les bases de données nosql de style document peuvent également offrir une approche qui n'est pas fausse.
Bien que je ne vais pas m'y plonger trop loin, il existe de nombreux tutoriels pour les listes de tâches dans le canapé. Un tel qui est venu avec une recherche est une simple application de liste des tâches dans CouchDB . Un autre apparaît dans le wiki couchdb: Schéma proposé pour les listes de tâches .
Dans l'approche appropriée pour un canapé, chaque liste est un document JSON stocké dans la base de données. Vous devez simplement placer la liste dans un objet JSON et la placer dans la base de données. Et puis vous lisez à partir de la base de données.
Le JSON pourrait ressembler à:
[
{"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}
]
(de la création d'une liste de courses avec un fichier json sur Stack Overflow).
Ou quelque chose qui s'approche de ça. Il y a une autre tenue de dossiers que le canapé a dans le document.
Le fait est que ce n'est pas la mauvaise façon d'approcher et qu'une liste de tâches dans une base de données de documents peut être parfaitement adaptée à ce que vous essayez de faire avec moins de frais généraux de concept pour savoir comment le faire.