网站匹配人员的数据库设计

Question

网站匹配人员的数据库设计

mysqldatabasedatabase-designweb-applicationsmatching

3

我正在创建一个Facebook网络应用程序，类似于约会网站的功能，让用户提供有关自己和匹配用户偏好信息。

我正在创建数据库，并考虑以下设计：

- Members表：使用FB ID作为主键，包含有关用户的信息。 - Preferences表：包含用户想要的偏好信息。

大约会有20个字段可供用户指定偏好，但所有字段都是可选的。我不确定结构“preferences”表的最佳方法，目前有两种思路：

方案1：使用Facebook ID的外键，并为每个可以匹配的字段添加一个新列。问题在于如果某个字段没有指定值，则数据库中将会存在很多“null”值。

- 数据库中的“null”值会占据空间或引起其他问题吗？

方案2：再次使用Facebook ID的外键，但在接下来的两列中使用键值对方法。因此，一列将包含用户偏好的ID，另一列将包含其值。对于每个用户偏好，我将以以下结构记录：“用户ID”-“偏好ID”-“值”。

- 问题是“值”列中的类型将取决于“偏好ID”列的内容。

我的问题：

- 哪种方法更好？ - 是否有标准的模式解决这种Web应用程序的问题？

- user1058210

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Joel Brown · Accepted Answer

正如你所注意到的，无论哪种方式，你都需要做出妥协。你选择哪种方案取决于你的生产数据实际情况。

在稀疏表中，null值占用一点空间，但不是很多——只要你的列使用可变长度数据。10个null varchars并不长。10个null ints与10个non-null ints一样长。

如果你添加第三个表格"PreferableThings"，并且以第二种解决方案中的"preference ID"为键进行索引，那么你拥有的就不是技术上的键值对或EAV（大多数人都避免）。如你所指出的困难在于，具有不同数据类型的首选项必须以通用编码形式（通常是varchar）存储。这解决了稀疏表的问题，但它强制你创建一些应用程序逻辑来从通用数据类型解码为正确的本机数据类型。你可以在"PreferableThings"表格上存储执行此操作的规则。

然而，第二种方法的另一个优点是，你可以通过表格驱动添加新的首选项选项。通过方案1，你需要进行模式更改。