数据库表的数量与表的大小

Question

我正在尝试为网站开发数据库。该网站已注册用户，这些用户可以与其他用户交朋友。就像任何传统的社交网站一样。现在我的问题是，我必须存储每个用户的朋友列表以及他的个人资料信息。每个用户都有自己的个人资料ID。除此之外，每个用户都可以为他的朋友创建组，还有一个状态字段，用于说明两个用户之间友谊的状态。

现在要做到这一点，我想到了两个解决方案：

1. 维护一个名为个人资料的表格，其中每个用户都有一个个人资料ID和他的其他个人资料信息，并有一个全局好友表，其中包含他的个人资料ID和他的朋友个人资料ID。其他领域将描述，小组，用户为特定朋友选择的以及他们的友谊状态等等。

2. 维护一个名为个人资料的表格，其中每个用户都有一个个人资料ID以及上面的其他个人资料信息，并为每个用户提供一个单独的朋友表，其中显示的内容类似于friends_profileid，每个用户都有自己的朋友列表其中包含所有其他信息。

以上哪两种技术更合适？我正在使用MySQL Server 5.0，我也考虑使用抽象数据类型和数组类型，但这使得前端实现变得更加复杂，困难和繁琐。虽然第一种技术是以非常高的速率增加单个表中的行数，但第二种技术是增加表的数量以与用户数量成比例？还有什么建议？更多表格或更多行数？

虽然第二种技术减少了单个表中搜索的负担，但是一次又一次地存储模式的开销是多少？对于这种情况，最好的方法是什么？

Answer 1

SQL旨在使用可变数量的行而不是固定的关系。

每个用户1个表的问题（就在我的脑海中）：

1. 坚持使用一堆难以访问且难以维护的表格。没有简单的方法来运行跨多个用户的查询。限制查询大小以尝试在单个查询中“分解”这些表。大多数SQL / ORM层都没有提供一种很好的方法来处理它。
2. 生成的查询需要是“动态的”，并且替换了不同的表。虽然这不会“改变形状”，但静态分析器很难/不可能知道这一点（也许这会引入概念一个“模板”？ - 更复杂。不，谢谢！）。这适用于验证SQL DDL / DQL是否有效（如果使用此类工具），无需额外工作就无法使用静态生成的ORM，并且会对查询处理器/分析器造成更多负担。
3. 可能/通常会导致更糟糕的查询计划和整体表现，因为在一般情况下，每个表（比如100k？不，谢谢！）需要独立处理可能缺乏逻辑位置。您可能还在推动一些较高的RDBMS限制（另一方面，有200万条记录的表格“很小”）。

结论：请使用您的RDBMS优势 - 世界已经运行了几十年的SQL（至少2 ;-)，并且大多数[平凡]问题已经解决了很多次。< / p>

Answer 2

您绝对不需要创建额外的每用户“朋友”表。对我有意义的方式更接近你的第一个解决方案：

我认为，传统的方法是使用连接表创建双向，多对多 >用户之间的映射。该表有两列，它们都是users表主键的外键。连接表中的条目（称为user_friends）表示两个用户之间的“友谊”。

Answer 3

不是根据表格来思考，而是考虑域名对象是什么，以及它们之间的关系是什么样的。

使用它来驱动您的数据库设计，然后将您的数据库结构封装在定义良好的API之后，这些API执行幕后所需的任何连接。