我正在创建一个新的数据库来管理愿望清单。
解决方案A：
两张桌子，
解决方案B：
一张桌子，
哪个更好？
解决方案A更好。无论何时尝试将集合存储在列而不是行中，您都会遇到问题。
溶液A标准化，溶液B不标准化。在大多数情况下，解决方案A将更好，更灵活。这不是真的主要时间是，如果您在大型表上创建一些复杂连接的汇总表，以用作常见问题的快速查询源。除非您正在构建数据集市，否则不太可能出现这种情况。使用解决方案A.
我肯定会选择第一个解决方案：
第二种解决方案只有在为了更容易缓存而被迫进行非规范化或者如果你的应用程序变得非常庞大且需要数据库分片时才会更好。在所有其他情况下，我更喜欢数据库的更清洁的设计。
多表复杂，因此，单表实用，简单，因此值得考虑。假设愿望列表是网站的一个功能，一些用户来了，创建用户帐户，然后列出他们的愿望，它可能不是很明显，但如果你想到它，需要问一个问题，为什么你想要有一个标题表定义愿望清单而不是只有第二个表，列出愿望。在我看来，对这种方法的需求表明每个用户（可能）想要拥有多个愿望清单。一个用于亲密的朋友和亲戚，一个用于太空船冒险计划在2050年年度:)否则所有的愿望可能整齐地列在愿望细节（第二）表中，没有第一个，为一个巨大的愿望清单（让我们称之为默认愿望清单，没有愿望的区别，是你想要的东西，或者计划在准备太空船冒险时完成的事情（可能你的所有愿望都成真！:)）。
回到表的设计，这是考虑因素。如果你不打算
而不是像长字符串字段那样存储列表允许单个表。
如果您需要2，则添加第二个表是合理的，但仍然可以通过将“长字符串”字段转换为带有属性的XML列来避免，其中您可以将希望的项目与一些其他注释和/或信息配对。
如果您需要1，则需要两个表解决方案，以便可以在愿望清单上的项目与与此特定项目相关的任何内容之间建立关系，即来自亲密朋友或亲戚的礼物，满足愿望，或者某事物比如存储在另一个表中的东西的目录。
如果您确实使用多表方法，则需要小心，以便列出单个所需项目的表没有没有匹配的标题条目定义列表本身的条目。通常，数据库使用外键来强制执行这种关系。因此，“item”表将需要一个包含父表中键的字段。
总而言之，您很可能会有2个或3个表。表1 - 列出用户帐户在最简单的情况下，该表将具有带有长字符串和/或XML列的字段“my wish list”。表2 - 使用密钥记录相关用户帐户来枚举用户愿望列表。表3 - 使用来自任一用户帐户的密钥（如果用户只能有一个愿望清单）枚举愿望项目，或者如果每个用户可以有多个不同的愿望清单，则使用表2。
最后，理论上，用户可以拥有共享的愿望清单。例如，凯特和西蒙计划在2025年结婚。他们希望在Vashon岛的一个小屋举行婚礼（线路很长，上次我检查这个地方是提前4年预订的）。在这种情况下，第四个表的可能性出现。此表将“用户”和“愿望清单”组合在一起，以启用愿望清单的加入所有权。
希望这可以帮助。
- 干杯！