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

时间:2012-07-27 11:08:28

标签: mysql database database-design web-applications matching

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

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

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

用户可以指定约20个字段,但所有字段都是可选的。我不确定构建我的“偏好”表的最佳方法,我目前有两个想法:

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

  • 数据库中的“null”值是占用空间还是导致其他问题?

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

  • 问题在于“值”列中的值类型取决于“首选项ID”列的内容

我的问题:

  • 哪种方法更好?
  • 这种Web应用程序是否有标准架构解决方案?

1 个答案:

答案 0 :(得分:2)

正如您所注意到的,无论哪种方式,您都在考虑妥协。你走哪条路取决于你的生产数据真实情况。

稀疏表中的空值确实占用了一点空间,但不是很多 - 只要您的列使用可变长度数据。十个null varchars不是很长。十个null int就像10个非null int一样长。

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

第二种方法的另一个优点是,您可以表驱动添加新的首选项选项。使用解决方案1,您将需要更改架构。