我正在我的网站上创建用户个人资料，但不知道如何设计：有很多字段，有些是 1:1，例如居住城市、生日等。但是有 50 多个字段是 1:many (或多对多？）比如最喜欢的电影、运动队、约会偏好、网名、电话号码、电子邮件地址等。当我们有以前工作过的公司、以前的学校等时，情况会变得更加复杂。一个人可以属于许多公司而且这个组里有很多字段，比如工作日期、部门、公司名称、行业名称等。
所以问题是如何存储所有这些？如果我们对所有这些配置文件字段进行规范化，将会有很多很多表要加入。据我所知，对于社交网络，人们推荐一种非规范化的方法。但无论如何，我将所有用户详细信息和个人资料详细信息存储在主用户表中，因此每一行都是唯一用户。如果我必须存储所有这些多重偏好，特别是喜欢的电影可以进入数百个和过去的公司本身有一个完整的字段组，所以用户表中会有很多重复项。
社交网络对此采取什么方法？
【问题讨论】：
标签： php mysql database schema social-networking
您必须坚持创建架构的规范化策略。查询可能是一种痛苦，您应该非常小心地处理，尤其是在处理连接时。如果您是一个点开发人员，我猜 LINQ 会处理 d 痛苦you.I 相信您的 RDMS 足够聪明，可以以出色的性能处理您的查询。需要注意的一件事是您的查询结构。编写基于性能的查询。正如我所说，LINQ 应该做得最好....干杯
【讨论】：
社交网络数据存储问题实际上与一般的数据存储问题没有什么不同......标准化和相关数据是有效“存储”这些数据的最佳方式。 RDBMS 用于处理这些关系 - PK-FK 关系和 JOINS 是关系数据库的主要点......所以即使你“看到”连接连接连接等，数据库在处理这些连接方面（应该）是有效的.
从获取相关数据的使用角度来看 - 确保您的索引准确且经过优化 - 并利用 VIEWS 来“展平”显示所需的数据...
因此，无论您使用什么应用程序服务器来获取数据，都会调用 VIEW - 这将“显示”给开发人员，作为数据的“更扁平”表示，使 UI 和 APP serer 交互更清洁、更高效（在资源和编码方面），
作为一般准则 - 在数据仓库环境中，数据的扁平化通常被认为是“可接受的”......当然，我不会引发关于“规范化程度如何，是‘规范化’”的可怕辩论（第一 - 第六形式的归一化...）
我想您可以将 SN 视为更多的 OLAP，而不是 OLTP。在这种情况下，“一些”非规范化数据存储是常见的——并且可以接受——实际上，你可以决定你想要的东西有多非规范化……例如——在你的例子中，就业历史和电影、体育。我认为一个简单的 1:many 允许在此类项目上重复条目会很好，并且可能更容易维护......
希望对你有帮助，
【讨论】：