通讯录数据库设计：非规范化？
Posted
技术标签:
【中文标题】通讯录数据库设计：非规范化？【英文标题】：Address book database design: denormalize? 【发布时间】：2011-05-29 17:37:58 【问题描述】：我正在设计一个类似联系人管理器/地址簿的应用程序，但无法确定数据库设计。
在我当前的设置中，我有一个联系人，其中包含地址、电话号码、电子邮件和组织。所有联系人属性当前都是单独的表，带有联系人表的 fk。不用说，一个联系人可以拥有任意数量的这些属性。
现在，如果我想将联系人读入应用程序，我会发现自己将所有这些表连接在一起。由于没有对相关表执行过滤、反向查找、排序等操作，将相关字段存储为联系人表的直接属性上的 json 编码列表不是更好/更简单的解决方案吗？
例如，不是将带有 fk 的联系人转换为具有 3 个条目的电话号码表，而是将所有电话号码编码并将它们存储到联系人表的字段中？
任何见解都非常感谢！ （仅供参考，我正在使用 Django，尽管这并不重要）
【问题讨论】：
【参考方案1】：您能保证您的应用永远不会需要这些其他功能吗？你真的想把自己画到角落里，以后不能轻易支持这一切吗？
通常，非规范化仅出于性能原因而发生。然后，仍然保留规范化数据的副本以供实时工作，非规范化数据用于离线处理，其中有静态快照就可以了。
习惯于编写连接。这就是 SQL 的工作方式。必须这样做并不意味着有问题。
【讨论】：
【参考方案2】：我知道我为时已晚，但对于任何有同样问题的人来说。
IMO，在这种情况下，元数据建模是可行的方法。 http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map
【讨论】：
【参考方案3】：听起来您建议将当前建模为五个 SQL 表的数据转换为常见的多值类型（您的 SQL 产品对此有很好的支持吗？）我认为这构成“非规范化”的唯一方法是如果您打算违反1NF，此时您不妨放弃 SQL 作为数据存储，因为您的数据将不再是关系型的！否则，您的数据仍将被规范化，但您将失去使用 SQL 查询其属性的能力（除非您的 SQL 产品具有查询多值属性的扩展）。决定因素似乎是：是否需要使用 SQL 查询这些属性？
【讨论】：
以上是关于通讯录数据库设计：非规范化？的主要内容，如果未能解决你的问题，请参考以下文章