Esquema de base de datos para una lista de tareas pendientes

Estoy tratando de hacer una aplicación de lista de tareas muy simple con PHP, MySQL, plantillas Jquery y JSON ... Sin embargo, mi esquema parece complicar las cosas en JSON.

¿Cuál es la mejor manera de hacerlo?

1. Una nueva tabla para cada lista, que contiene los elementos.

o

2. ¿una tabla para listas y una tabla para elementos que están unidos de alguna manera? ¿Porque he intentado esto y no parece ser la forma correcta de hacerlo? Ejemplo http://jsfiddle.net/Lto3xuhe/

Hay una broma que escuché hace un tiempo:

P ¿Cómo cuenta un codificador BASIC hasta 10?
A 1,2,3,4,5,6,7,8,9,10

P ¿Cómo cuenta un codificador C hasta 10?
A 0,1,2,3,4,5,6,7,8,9

P ¿Cómo cuenta un DBA hasta 10?
A 0,1, muchos

La verdad detrás de esta broma es que una vez que tienes dos (o más) de lo mismo en una estructura de base de datos (columnas o tablas), lo estás haciendo mal.

Un esquema que se parece a:

+----------+
| id       |
| name     |
| phone1   |
| phone2   |
|          |
+----------+

Está mal porque ¿dónde pondrás un tercer número de teléfono si alguien lo tiene?

Lo mismo se aplica a las tablas mismas. También es malo modificar el esquema en tiempo de ejecución, lo que parece implicar la "nueva tabla para cada lista". (Relacionado: MVC4: ¿Cómo crear un modelo en tiempo de ejecución? )

Y por lo tanto, la solución es crear una lista de tareas que consta de dos tablas. Hay dos cosas que tiene: listas y elementos.

Entonces, hagamos una estructura de tabla que refleje esto:

+----------+       +-------------+
| List     |       | Task        |
+----------+       +-------------+
| id (pk)  <---+   | id (pk)     |
| name     |   +---+ listid (fk) |
|          |       | desc        |
|          |       |             |
+----------+       +-------------+

La lista tiene una identificación (la clave principal de la lista) y un nombre. La tarea tiene una identificación (la clave principal), un listid (una clave externa) y la descripción de la tarea. La clave foránea se relaciona con la clave primaria de otra tabla.

Señalaré que esto no comienza a abarcar todas las posibilidades en varios requisitos para el software y la estructura de la tabla para soportarlo. Completado, fecha de vencimiento, repetición, etc. Estas son estructuras adicionales que probablemente deberán considerarse al diseñar la tabla. Dicho esto, si la estructura de la tabla no está normalizada adecuadamente (o no se da cuenta de las compensaciones que ha realizado porque no está normalizada), tendrá muchos dolores de cabeza más adelante.

Ahora, todo lo relacionado con escribir esto como una base de datos relacional. Pero ese no es el único tipo de base de datos que existe. Si considera que una lista es un documento, las bases de datos nosql con estilo de documento también pueden ofrecer un enfoque que no está mal.

Si bien no voy a profundizar demasiado, hay numerosos tutoriales para listas de tareas pendientes en el sofá. Uno de los que surgió con una búsqueda es una aplicación simple de lista de tareas en CouchDB . Otro aparece en el wiki de couchdb: Esquema propuesto para listas de tareas .

En el enfoque apropiado para un sofá, cada lista es un documento JSON almacenado en la base de datos. Simplemente pondría la lista en un objeto JSON y la colocaría en la base de datos. Y luego lees de la base de datos.

El JSON podría verse así:

[
 {"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}
]

(desde la creación de una lista de compras con un archivo json en Stack Overflow).

O algo parecido a eso. Hay otros registros que ese sofá tiene como parte del documento.

La cuestión es que no es la forma incorrecta de acercarse y una lista de tareas pendientes en una base de datos de documentos puede ser perfectamente adecuada para lo que está tratando de hacer con menos sobrecarga conceptual sobre cómo hacerlo.

La opción 2 es una configuración maestra / detallada tradicional. Eso es probablemente lo que quieres aquí. Coloque la identificación de la lista en la tabla de elementos y únase a eso. El esquema no debería afectar al JSON. Su consulta podría verse algo así como:

select lists.name as list_name, items.name as item_name 
from items 
join lists on (lists.id = items.list_id)

No trataría de vincular su representación de UI o transmisión de datos a la UI directamente a cómo piensa almacenar los datos. Al mantener a los dos separados y usar un poco de lógica de middleware para casarse, los dos le permiten alterar fácilmente ambos lados sin impactar al otro de manera crítica.

Desde una perspectiva de almacenamiento de datos, es probable que use la opción 2 que sigue el patrón de datos normalizado típico donde las partes comunes se descomponen en sus propias tablas para evitar la repetición y minimizar la hinchazón de la base de datos.

Desde una perspectiva de vista, simplemente necesita usar una consulta de base de datos para unir los datos pertinentes en un conjunto de resultados y luego iterar ese resultado y generar una respuesta json aplicable a sus necesidades de IU. Lo que probablemente quiera hacer es alimentar los datos en JSON para que se ajusten a sus necesidades de IU de la mejor manera posible, a menudo eliminando la necesidad de lógica de scripting adicional en sus páginas web.