mysql - 与人相匹配的网站数据库设计

Question

我正在创建一个 Facebook 网络应用程序，其功能与约会网站类似，方法是让用户提供有关他们自己的信息以及他们在匹配用户中的偏好信息。

我正在为此创建数据库并考虑以下设计:

• Members 表: 包含有关使用 FB ID 作为主键的用户的信息。
• 偏好表:包含有关用户想要的偏好的信息。

大约有 20 个字段，用户可以在其中指定首选项，但所有字段都是可选的。我不确定构建“首选项”表的最佳方式，目前我有两个想法:

解决方案 1: 使用 facebook ID 的外键，并为每个可以匹配的字段创建一个新列。我看到的一个问题是数据库中将有很多未指定值的字段的“空”值。

• 数据库中的“空”值是否占用空间或导致任何其他问题？

解决方案 2:再次使用 facebook ID 的外键，但在接下来的两列中使用键值对方法 - 因此一列将包含用户偏好的 ID，另一列将包含它的值。对于每个用户偏好，我都会有一个结构记录:“用户 ID”-“偏好 ID”-“值”。

• 问题在于“值”列中的值类型将取决于“偏好 ID”列的内容

我的问题:

• 哪种方法更好？
• 是否有适用于此类网络应用程序的标准模式解决方案？

Answer 1

正如您所注意到的，无论哪种方式，您都在寻求妥协。您采用哪种方式取决于您的生产数据的实际情况。

稀疏表中的空值确实会占用一点空间，但不会占用太多——只要您的列使用可变长度数据即可。十个 null varchars 不是很长。十个空整数与十个非空整数一样长。

如果您在第二个解决方案中添加以“偏好 ID”为键的第三个表“PreferableThings”，那么从技术上讲，您拥有的不是大多数人回避的键值对或 EAV。正如您所指出的，困难在于具有不同数据类型的首选项必须以通用编码形式(通常是 varchar)存储。这解决了稀疏表的问题，但它迫使您创建一些应用程序逻辑以从通用数据类型解码为正确的 native 数据类型。您可以将执行此操作的规则存储在“PreferableThings”表中。

然而，第二种方法的另一个优点是您可以表驱动添加新的首选项。对于解决方案 1，您需要更改架构。