待办事项列表的数据库架构

我正在尝试使用PHP，MySQL，Jquery模板和JSON创建一个非常简单的待办事项列表应用程序。但是，我的架构似乎使JSON变得复杂。

最好的方法是什么？

1. 每个列表的新表，其中包含项目。

要么

2. 一个用于列表的表，以及一个以某种方式连接的项目的表？因为我已经尝试过了，这似乎不是正确的方法？范例http://jsfiddle.net/Lto3xuhe/

不久前我听到一个笑话：

问：BASIC编码器如何计数到10？
一个 1,2,3,4,5,6,7,8,9,10

Q C编码器如何计数到10？
A 0、1、2、3、4、5、6、7、8、9

问：DBA如何计数到10？
A 0,1，很多

这个笑话背后的真相是，一旦在数据库结构（列或表）中有两个（或多个）相同的事物，您就做错了。

如下所示的架构：

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

是错误的，因为如果有人拥有，您将在哪里放置第三个电话号码？

表本身也是如此。在运行时修改架构也是一件坏事，“每个列表的新表”似乎暗示着这一点。（相关：MVC4：如何在运行时创建模型？）

因此，解决方案是创建一个由两个表组成的待办事项列表。您有两件事-列表和项目。

因此，让我们创建一个反映此情况的表结构：

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

该列表具有一个ID（列表的主键）和一个名称。任务具有一个ID（主键），一个listid（一个外键）和任务描述。外键与另一个表的主键相关。

我要指出的是，这并没有涵盖软件和支持它的表结构的各种要求中的所有可能性。完成，到期日，重复等...这些都是在设计表时可能需要考虑的所有其他结构。就是说，如果表结构不是经过适当规范化的结构（或者由于未进行规范化而实现了权衡），那么以后您会头疼不已。

现在，所有与将其编写为关系数据库有关的内容。但这不是唯一的数据库类型。如果您将列表视为文档，则样式为nosql数据库的文档也可以提供一种正确的方法。

虽然我不会深入研究它，但是有很多教程可以在沙发上找到待办事项。通过搜索得出的一个例子是CouchDB中的一个简单的Task-list应用程序。另一个出现在couchbed Wiki中：待办事项列表的建议架构。

在适用于沙发的方法中，每个列表都是存储在数据库中的JSON文档。您只需将列表放入JSON对象中，然后将其放入数据库中。然后您从数据库中读取。

JSON可能类似于：

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

（通过在Stack Overflow上使用json文件创建购物清单）。

或接近的东西。还有其他一些记录，该记录是文档的一部分。

关键是，它不是错误的方式方法，并在文档数据库中的待办事项列表，可以完全适合你正在尝试用更少的概念开销做怎么做。

选项2是传统的主/详细设置。那可能就是您想要的。将列表ID放在items表中，然后加入。模式不应该影响JSON。您的查询可能类似于：

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

我不会尝试将您的UI表示形式或数据到UI的传输直接与您打算如何存储数据联系起来。通过将两者分开并使用一些中间件逻辑将两者结合起来，您可以轻松更改任何一方，而不会以关键的方式影响另一方。

从数据存储的角度来看，您可能会使用选项2，该选项遵循典型的规范化数据模式，在该模式中，将通用部分分解到自己的表中，以避免重复并最大程度地减少数据库膨胀。

从角度来看，您只需要使用数据库查询将相关数据加入结果集中，然后对该结果进行迭代并生成适用于您的UI需求的json响应。您可能想要做的就是将数据馈入JSON，以使其尽可能满足您的UI需求，通常不需要在网页中使用其他脚本逻辑。