在数据库中存储多个选择值

Question

假设我提供用户检查她说的语言并将其存储在数据库中.重要的一点是,我不会搜索db中的任何值,因为我将有一些单独的搜索引擎用于搜索.现在,存储这些值的显而易见的方法是创建一个表格

UserLanguages
(
 UserID nvarchar(50),
 LookupLanguageID int
)

但该网站将是高负荷,我们正试图消除任何可能的开销,所以为了避免在UI上显示结果时与主成员表的连接,我想在主表中为用户存储语言,拥有它们逗号分隔,如"12,34,65"

同样,我不搜索它们,所以我不担心必须在该列上进行全文索引.

我真的没有看到这个解决方案的任何问题,但我忽略了什么？

谢谢,安德烈

Answer 1

别.

• 你不搜索它们现在
• 除了这种情况,数据对任何事都没用
• 没有数据完整性(例如没有FK)
• 您仍然需要更改为"英语,德语"等进行显示
• "给我所有说x的用户"=失败
• 该列表实际上是一个演示问题

不过,这是你的系统,我期待以后回答不可避免的"帮助"问题......

Answer 2

你现在可能不会遗漏任何东西,但是当你的需求发生变化时,你可能会后悔这个决定.你应该像你建议的第一直觉那样将它标准化.这是正确的方法.

你所建议的是经典的过早优化.您还不知道该加入是否会成为瓶颈,因此您不知道您是否真的在购买任何性能改进.等到您可以对事物进行分析,然后您就会知道是否需要对该部分进行优化.

如果是这样,我会考虑一个物化视图,或者使用规范化数据预先计算答案的一些其他方法到不被视为记录簿的缓存.

更一般地说,如果需要,可以进行许多可能的优化,而不会以您建议的方式影响您的设计.

Answer 3

这种类型的存储几乎总是回来困扰我.首先,你甚至不是第一个正常的形式.对于另一个,一些经理或其他人肯定会回来说..."嘿,既然我们存储了这个,你能不能给我写一份关于...的报告？"

我建议采用标准化设计.把它放在一个单独的表中.

Answer 4

问题:

1. 你失去了加入能力(显然).
2. 您必须在每个页面加载/回发时重新分析列表.这导致更多的代码客户端.
3. 你失去了试图保持数据库完整性的所有借口.想象一下,如果您决定稍后再删除一种语言...修复所有用户配置文件的SQL是什么？
4. 假设您的各种配置文件选项存储在数据库的查找表中,您仍然需要为每个配置文件页面运行"30个查询".如果不是,那么您必须为每个小改动进行代码部署.坏,非常糟糕.
5. 基于"不会发生"的事情做出设计决策是失败的绝对秘诀.当然,商界人士说他们永远不会这样做......直到他们想到一个他们绝对必须这样做的理由.今天.完成编码后会立即执行此操作.
6. 正如我在评论中所述,对低使用率页面的30个查询都不算什么.不要冒汗,绝对不要优化,除非你知道必须确保它是必要的.猜猜SO为它的个人资料页面做了多少查询？