假设我提供用户检查她说的语言并将其存储在数据库中。重要的一点是,我不会搜索db中的任何值,因为我将有一些单独的搜索引擎用于搜索。 现在,存储这些值的显而易见的方法是创建一个类似
的表UserLanguages
(
UserID nvarchar(50),
LookupLanguageID int
)
但该站点将是高负载,我们正试图消除任何可能的开销,所以为了避免在UI上显示结果时与主成员表连接,我想在主表中为用户存储语言,用逗号分隔,如“12,34,65”
同样,我不会搜索它们,所以我不担心必须在该列上进行全文索引。
我真的没有看到这个解决方案有任何问题,但是我忽略了什么吗?
谢谢, 安德烈
答案 0 :(得分:15)
别。
这是你的系统,我期待以后回答不可避免的“帮助”问题......
答案 1 :(得分:12)
你现在可能不会遗漏任何东西,但是当你的要求发生变化时,你可能会后悔这个决定。你应该像你建议的第一直觉那样将它标准化。这是正确的方法。
您所建议的是经典的过早优化。您还不知道该加入是否会成为瓶颈,因此您不知道您是否真的在购买任何性能改进。等到你可以分析这个东西,然后你就会知道是否需要对这个东西进行优化。
如果确实如此,我会考虑一个物化视图,或者其他一些方法,它使用规范化数据预先计算答案,并将其作为不被视为记录簿的缓存。
更一般地说,如果有必要,可以进行许多可能的优化,而不会以您的建议方式影响您的设计。
答案 2 :(得分:11)
这种类型的存储几乎总是回来困扰我。首先,你甚至不是第一个正常的形式。对于另一个,一些经理或其他人肯定会回来说...“嘿,既然我们存储了这个,你能不能给我写一份报告...”
我建议采用标准化设计。把它放在一个单独的表中。
答案 3 :(得分:5)
问题:
答案 4 :(得分:4)
我通常会忽略您描述的解决方案,当您以这种方式存储关系数据时,您会遇到麻烦。
作为替代解决方案: 您可以存储为一个位掩码整数,例如: 0 - 没有选择 1 - 英语 2 - 西班牙语 4 - 德语 8 - 法国人 16 - 俄语 - 等等2的权力
因此,如果某人选择了英语和俄语,那么该值将为17,您可以使用按位运算符轻松查询这些值。
答案 5 :(得分:4)
过早优化是万恶之源。
编辑: 显然我观察的背景被一些人误解了 - 因此也就是暗示。所以我会澄清。
使模型非规范化以使事情更容易和/或“更高性能” - 例如创建连接列来表示业务信息(如OP案例中) - 我称之为“过早优化”。
虽然可能存在一些极端边缘情况,其中没有其他方法可以获得特定问题域所需的必要性能 - 但应该很少假设是这种情况。一般来说,这种过早的优化会导致长期的悲痛,因为它们难以撤消 - 一旦生产数据模型,更改数据模型比最初部署时需要更多的努力。
在设计数据库时,开发人员(和DBA)应该应用规范化等标准实践,以确保其数据模型表达正在收集和管理的业务信息。我不认为正确使用数据规范化是一种“优化” - 这是一种必要的做法。在我看来,数据建模者应该始终关注可以重构为(至少)第三范式(3NF)的模型。
答案 6 :(得分:2)
如果您不是在查询它们,那么您不会因为最初计划的形式存储任何内容而丢失任何内容。 如果你是这样,那么以逗号分隔的格式存储它们会回来困扰你,我怀疑任何速度节省都会很重要,特别是当你考虑转换它们所需的工作时。
答案 7 :(得分:1)
您似乎非常担心添加一些额外的查找表连接。根据我的经验,实际传输HTML响应并让浏览器呈现它所花费的时间远远超过一些额外的表连接。特别是如果您使用主键和外键的索引(就像您应该这样)。这就像你计划进行多日越野之旅,你担心额外的10分钟浴室停留。
缺乏长期灵活性和数据完整性对于这么小的优化是不值得的(可能没有必要甚至不可察觉)。
答案 8 :(得分:0)
Nooooooooooooooooo !!!!!!!!
正如以上几篇文章所述。
如果你想对这场辩论有一个相反的看法,那就看看wordpress。表格充满了分隔数据,这是一个很棒的简单平台。