Sql 在数据库中存储多项选择值

假设我让用户检查她所说的语言并将其存储在数据库中。重要的一点是，我不会在db中搜索任何这些值，因为我将使用一些单独的搜索引擎进行搜索。 现在，存储这些值的明显方法是创建一个类似

UserLanguages
(
 UserID nvarchar(50),
 LookupLanguageID int
)

但是该站点的负载将很高，我们正在尽可能消除任何开销，因此为了避免在UI上显示结果时与主成员表连接，我考虑将用户的语言存储在主表中，以逗号分隔，如“12,34,65”

同样，我不搜索它们，所以我不担心必须对该列进行全文索引

我真的看不出这个解决方案有什么问题，但我是否忽略了什么

谢谢，

---

安德烈

这种类型的存储几乎总是萦绕在我心头。首先，你甚至还没有处于第一正常状态。另一方面，一些经理或其他人肯定会回来说。。“嘿，既然我们储存了这个，你能给我写一份关于……的报告吗？”

我建议采用规范化设计。把它放在另一张桌子上。

不要

• 你现在不需要搜索它们
• 除了这一情况，数据对任何东西都是无用的
• 无数据完整性（如无FK）
• 您仍然需要更改为“英语、德语”等进行显示
• “给我所有说x的用户”=失败
• 列表实际上是一个演示问题

---

不过，这是您的系统，我期待着稍后回答不可避免的“帮助”问题……

我通常不讨论您描述的解决方案，您以这种方式存储关系数据时会自找麻烦

作为替代解决方案： 可以存储为一个位掩码整数，例如： 0-无选择 1-英语 2-西班牙语 4-德语 8-法语 16-俄语 --依此类推2的幂

---

因此，如果有人选择英语和俄语，则值为17，您可以使用位运算符轻松查询值。

您现在可能没有遗漏任何内容，但当您更改需求时，您可能会后悔该决定。你应该按照你的第一直觉来储存它。这是正确的方法

你的建议是典型的过早优化。您还不知道加入是否会成为瓶颈，因此也不知道您是否真的在购买任何性能改进。等到你可以分析这个东西，然后你就会知道这个部分是否需要优化

如果是这样的话，我会考虑一个物化视图，或者一些其他的方法，它使用归一化的数据预先计算出一个不被认为是记事本的缓存。

---

更一般地说，如果有必要，可以进行很多可能的优化，而不会以您建议的方式影响您的设计。

过早优化是万恶之源。

编辑：很明显，我观察的背景被一些人误解了，因此也被投了反对票。所以我会澄清

对模型进行非规范化以使事情变得更简单和/或“更高效”——例如创建连接列来表示业务信息（如OP案例中所示）——就是我所说的“过早优化”

虽然可能存在一些极端的边缘情况，在这种情况下，没有其他方法可以获得特定问题领域所需的必要性能，但很少有人会假设这种情况。一般来说，这种过早的优化会导致长期的痛苦，因为它们很难撤消—一旦数据模型投入生产，更改它要比最初部署时花费更多的精力

---

在设计数据库时，开发人员（和DBA）应该应用标准实践，如规范化，以确保他们的数据模型表达收集和管理的业务信息。我不认为正确使用数据规范化是一种“优化”——它是一种必要的实践。在我看来，数据建模师应该始终注意那些可以（至少）重组为第三范式（3NF）的模型。

如果您没有对它们进行查询，那么将它们存储在类似初始计划的表单中不会丢失任何东西。 如果是，那么以逗号分隔的格式存储它们会再次困扰您，我怀疑任何速度节约是否会显著，尤其是当您考虑到将它们翻译回来所需的工作时。

问题：

您将失去加入功能（显然）

您必须在每次加载/发回页面时重新分析列表。这会在客户端产生更多的代码

你失去了保持数据库完整性的所有伪装。想象一下，如果你决定以后删除一种语言。。。修复所有用户配置文件的sql是什么

假设您的各种配置文件选项存储在数据库的查找表中，您仍然需要在每个配置文件页面上运行“30个查询”。如果它们不是，那么您必须为每一个小更改进行代码部署。糟糕，非常糟糕

将设计决策建立在“不会发生”的基础上绝对会导致失败。当然，生意人说他们永远不会那样做。。。除非他们想出一个理由，否则他们绝对必须这么做。今天这将在您完成编码后立即进行

正如我在一篇评论中所说的，30个查询对于一个低使用率的页面来说算不了什么。不要担心，除非你确定这是必要的，否则绝对不要优化。猜猜它的个人资料页面有多少查询

---

不

正如上面几篇文章所说的那样

---

如果你想对这场辩论持相反的观点，可以看看wordpress。表中充满了分隔数据，这是一个很棒的简单平台。

您似乎非常担心添加一些额外的查找表联接。根据我的经验，交流所需的时间