社交网络 - 用户个人资料设计架构问题
我正在我的网站上创建用户配置文件，但不知道如何设计：有很多字段，有些是 1:1，例如居住城市、生日等。但是有 50 多个字段是 1:多（或多对多）很多？）比如最喜欢的电影、运动队、约会偏好、屏幕名称、电话号码、电子邮件地址等。当我们以前工作过的公司、以前的学校等时，事情会变得更加复杂。一个人可以属于许多公司，并且有这个组中有很多字段，比如工作日期、部门、公司名称、行业名称等。
那么问题是如何存储所有这些？如果我们规范化所有这些配置文件字段，将会有很多表需要连接。据我所知，对于社交网络，人们推荐采用非规范化方法。但无论如何，我将所有用户详细信息和个人资料详细信息存储在主用户表中，因此每一行都是一个唯一的用户。如果我必须存储所有这些多重偏好，特别是像最喜欢的电影可以有数百个，过去的公司本身有一整组字段，所以用户表中会有很多重复项。
社交网络为此采取了什么方法？
I am creating user profiles on my site and lost on how to design this: There are many fields, some are 1:1 like city of residence, birthday, etc. But there are over 50 fields which are 1:many (or many to many?) like favorite movies, sport teams, dating preference, screen names, phone numbers, email addresses etc. It gets more complex when we have previous companies worked at, previous schools, etc. A person can belong to many companies and there are many fields in this group like Date worked at, department, company name, industry name, etc.
So the question is how to store all this? If we normalize all these profile fields there will be many many tables to join. As far as i read, for social networks people recommend a denormalized approach. But eitherways, I am storing all user details and profile details in the main user table, so each row is a unique user. If i have to store all these multiple preference, esp like favorite movies can go in the hundreds and past companies itself have a whole group of fields, so there will be lots of duplicates in the user table.
What approach do social networks take for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
社交网络数据存储问题实际上与一般的数据存储问题没有什么不同……标准化和相关的数据是有效“存储”这些数据的最佳方式。 RDBMS 是为了处理这些关系而设计的 - PK-FK 关系和 JOINS 是关系数据库的要点...所以即使您“看到”join join 连接等，数据库（应该）在处理这些连接方面是有效的 从获取相关数据的使用角度来看，
确保您的索引准确且经过优化，并利用视图“展平”显示所需的数据……
因此，无论您使用什么应用程序服务器来获取数据数据将调用 VIEW - 它将“显示”给您（开发人员），作为数据的“更扁平”表示，使 UI 和 APP 服务器交互更干净、更高效（无论是在资源方面，还是在编码方面），
作为一般指南 - 在数据仓库环境中，数据扁平化通常被认为是“可接受的”......当然，我不知道如何展开“标准化程度如何”的可怕辩论（标准化的第一 - 第六种形式） ...)
我想您可能会认为 SN 更像是 OLAP，而不是 OLTP。在这种情况下，“某些”非标准化数据存储是常见的 - 并且可以接受 - 实际上，您可以决定您想要的东西的非标准化程度......例如 - 在您的示例中，工作历史和电影，体育。我认为简单的 1:many 允许在此类项目上重复输入就可以了，而且可能更容易维护...
希望这有帮助，
Social network data storage questions are really no different than the data storage questions in general... normalized and related data is the best way to 'store' this data efficiently. The RDBMS is made to handle these relationships - the PK-FK relationships and JOINS are the MAIN point of Relational DBs... so even though YOU 'see" join join join etc, the DB is (should be) efficient in handling these joins.
From a USAGE standpoint of getting to the pertinent data - make sure your indexes are accurate and optimized - and make use of VIEWS to 'flatten' the data you need for display purposes...
So whatever application server you are using to get the data will call the VIEW - that will 'appear' to you, the developer, as a 'flatter' representation of the data, making UI and APP serer interaction cleaner and more efficient (both in resources, and in coding),
as a general guideline - flattening of data is generally considered 'acceptable' in a data warehousing environment... of course I don't what to open up the monstrous debate of "just how normalized, is 'normalized'" (first - sixth form of normalization...)
I guess you could think of a SN as more of an OLAP, than the OLTP. In which case 'some' de-normalized data storage is common - and acceptable - really, YOU get to decide just how de-normalized you want things... For instance - in your examples, of employment history and movies, sports. I'd think that a simple 1:many allowing duplicate entries on such items would be fine, and probably easier to maintain...
Hope that was helpful,
您必须坚持创建模式的规范化策略。查询可能是一种痛苦，您应该极其谨慎地处理，尤其是在处理连接时。如果您是点开发人员，我想 LINQ 会为您处理这些痛苦。相信您的 RDMS 足够智能，能够以出色的性能处理您的查询。需要注意的一件事是你的查询结构。编写基于性能的查询。正如我所说，LINQ 应该做得最好......干杯
You have to stick with the normalization strategy of creating your schema.The query might be a pain which you should handle with extreme caution especially when dealing with joins.If you are a dot developer, i guess LINQ will handle d pain for you.I believe your RDMS is smart enough to handle your queries with great performance. One thing to take note is your query structure.Write performance-based queries.As i said, LINQ should do this best....cheers