3

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

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

  • 成员表： 包含有关使用其 FB ID 作为主键的用户的信息。
  • 首选项表： 包含有关用户想要的首选项的信息。

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

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

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

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

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

我的问题：

  • 哪种方法更好？
  • 这种网络应用程序有标准的模式解决方案吗？
4

1 回答 1

2

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

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

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

然而，第二种方法的另一个优点是您可以通过表格驱动添加新的偏好选项。使用解决方案 1，您将需要更改架构。

于 2012-07-27T11:43:19.303 回答