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