MySQL 表设计结构用户偏好

Posted 2023-04-15

【中文标题】MySQL 表设计结构用户偏好

【英文标题】：MySQL Table Design Structure User Preferences

【发布时间】：2012-09-15 16:59:14

【问题描述】：

我最近的任务是帮助建立一个约会网站的数据库。我对数据库的概念一点也不陌生，但我遇到了障碍，不知道如何继续。

请注意，我已经尝试寻找答案，但结果都不是很清楚，这就是我自己问这个问题的原因。此外，我熟悉 1 对 1、1 对多和多对多的概念。

网站的用户将选择他们在匹配中寻找的内容，并提供他们自己的信息进行匹配。

每个用户有 8 或 9 个属性。其中 3 个属性可以有多个值，我可以描述它的最佳方式是一组应该可搜索的复选框（例如，用户可以具有外向、关怀和有趣的个性）。

根据我的搜索，最受欢迎的答案是：

在一个表中的每个复选框都有一个字段 使用多对多关系，每个复选框都是表中的记录

而且，我应该存储他们正在查找的内容，还是应该将其保留为用户自行运行的查询？

如果我存储用户正在查找的内容，他们将搜索相同的 8 到 9 个属性，但它们都可能包含多个值（例如，您只能是一种性别，但您可能正在寻找某人任何性别）。

我希望能够存储用户在匹配中寻找的内容，以便可以自动建议匹配，但我不知道如何以有效的格式创建这种结构，如果有的话。

但我不知道其中哪一个或我不知道的第三种解决方案最适合网站设计。我原本以为我可以让每个属性都有多个值，一个 BIT 字段，每个位都是一个复选框，但后来我意识到我不知道我是否可以有效地查询该信息。如果有办法让我做到这一点，我会更喜欢这种方法，只要没有性能问题。

参与的每个人都希望该网站会变得流行，所以我想知道为大量用户提供服务的最佳结构。

如果我的问题已经有了答案，我深表歉意，我发现没有一个答案适合我的情况，而且我真的不知道如何为搜索引擎表达我的问题。

感谢您能给我的任何帮助。

【参考方案1】：

你想多了。暂时把它全部放在一张桌子上。当您看到数据集的类型/大小时，您始终可以对其进行优化并编写 sql 以使其产生相同的输出。

在实际实施之前不要进行优化。这听起来还不会有数十亿行。