database-design - 具有 20 个属性的用户配置文件的数据库表结构

Question

让我们以一个拥有 100.000 个用户的约会网站为例。每个用户有大约 30 个属性，如头发颜色、吸烟、年龄、城市、性别……一些属性是 bool、一些 int 和一些 var 或 text。

其中大约 20 个属性是可搜索的，一半的用户不填写数据。所有值都显示在用户个人资料页面上。

我在考虑以下选项：

1. 将数据拆分为 4 个表。表 1 用于搜索最多的数据，表 2 用于大部分未填充的属性，表 3 用于像 about me 这样的大数据，以及表 4 的其余部分。
2. 大多数属性都有单独的表，因此每个属性都有自己的表。
3. 使用 EAV 模型。

我认为第一个选项是最好的。或者有没有其他更好的方法？

Answer 1

假设您不需要添加新属性，您可能最好将所有内容放在一张大表中。DBMS 在存储 NULL 方面通常相当有效。索引 NULL 也应该是合理的，一些 DBMS 甚至不包括索引中的 NULL (Oracle)。

也不要害怕 BLOB - 它们会倾向于“拉伸”行（如果 BLOB 的一部分被内嵌放置在行中，这通常可以通过 DBMS 特定的方式进行控制），从而降低您的“数据集群” ，但这对于您的目的来说应该不是太重要。

无论如何，在确定最自然的解决方案性能不足之前，请先测量具有代表性的数据量。