我正在设计一个联系人管理器/类似地址簿的应用程序，但无法解决数据库设计问题。地址簿数据库设计：denormalize？
在我目前的设置中，我有一个联系人，其中包含地址，电话号码，电子邮件和组织。所有联系人属性目前都是单独的表，其中包含联系人表的fk。不用说联系人可以拥有任何数量的这些属性。
现在，如果我想要将联系人读入应用程序，我发现自己将所有这些表格连接在一起。由于没有过滤器，反向查找，排序等在相关表上执行，是不是一个更好/更简单的解决方案将相关字段存储为联系人表的直接属性上的json编码列表？
例如，而不是联系fk到有3个条目的电话号码表，只需编码所有电话号码并将它们存储到联系人表的字段中？
任何见解真的很感激！ （尽管我使用的是Django，但这并不重要）
你能保证你的应用永远不会增长到需要这些其他功能吗？你真的想在自己的角落画画，以至于以后你不能轻易支持这一切吗？
一般而言，非规范化只发生在性能方面的原因。然后，规范化数据的副本仍保留用于实时工作，非规范化数据用于具有静态快照的离线处理。
习惯写作连接。这就是SQL的工作方式。必须这样做并不意味着有什么错误。
我知道我太迟了，但对于任何人都有同样的问题。
国际海事组织，在这种情况下，元数据建模是要走的路。 http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map
听起来像你建议采取数据当前建模为五个SQL表并将其转换为一个通用的多值类型（您的SQL产品是否有良好的支持？）唯一的方法，我可以看到这将构成'非规范化'将是如果你建议违反1NF，那么你可能会放弃SQL作为数据存储，因为你的数据将不再是关系型的！否则，您的数据仍将被标准化，但您将失去使用SQL查询其属性的能力（除非您的SQL产品具有查询多值属性的扩展名）。决定性因素似乎是：你是否需要使用SQL查询这些属性？
+1 ...我同意100％！ – 2010-12-23 00:34:41