DB Row length/complexity vs Row count:是否有前者的理由？

Question

我们有一个db表，我称之为TIMES。它传统上看起来像这样：

ID    Blah1 Blah2 Blah3  Description
1     a     b     c      Day
2     d     e     f      Night

(我添加Blah列主要是为了显示表中存在更多列，但这些列与我们正在尝试进行的升级没有直接关系。)

我们希望在从db获得的结果中添加一些语言支持。所以我的建议是：

a)走懒惰的道路，只需为语言添加一个新的列，给我们

ID    Blah1 Blah2 Blah3  Description  Language
1     a     b     c      Day          English
2     d     e     f      Night        English
1     a     b     c      Tag          German
2     d     e     f      Nacht        German

或者，最好是b)执行一些标准化，并创建一个仅包含相关值的新表：

ID      Description  Language
1       Day          English
2       Night        English
1       Tag          German
2       Nacht        German

我们的数据库人员说，好吧，我们可以只使用原始表，并以xml...that的方式包含我们将保存在行上的所有内容。

ID        Blah1 Blah2 Blah3  Language
1         a     b     c      <TimeDescriptions>
                                 <TimeDescription language='English'>
                                     Day
                                 </TimeDesciption>
                                 <TimeDescription language='German'>
                                     Tag
                                 </TimeDesciption>
                             </TimeDescriptions>        
2         d     e     f      <TimeDescriptions>
                                 <TimeDescription language='English'>
                                     Night
                                 </TimeDesciption>
                                 <TimeDescription language='German'>
                                     Nacht
                                 </TimeDesciption>
                             </TimeDescriptions> 

“在行上保存”？我不是一个真正的db人，但对我来说这听起来很奇怪。当然，它会节省一些rows...but，当行本身更长时，总体来说这是一种胜利吗？(很有可能)除此之外，它看起来违反了我习惯的规范化规则。我还知道可以在SQL中使用XML并对其进行搜索(尽管我没有这样做过，并且对细节也不太了解)，但我就是看不到这样做有什么好处。

当我问他的时候，他开始变得易怒，所以我退后了，但我仍然想知道我是不是漏掉了什么。显然，许多细节都缺失了，但我并不是在寻找详细的分析……我只是想知道这是否可能是合理的。

编辑:啊。你可能会认为我已经在这里学习了足够长的时间来学习正确的格式，但我不知何故搞砸了最后一点……我会试着修复它，但欢迎进行其他编辑。

Answer 1

当然，它会节省一些rows...but，当行本身更长时，总体来说这是一种胜利吗？

有可能。但是这意味着一个页面可以容纳的行更少，这通常意味着更多的磁盘访问和更多的磁盘I/O。这些行现在看起来还不错，但是如果您支持十几种语言，那么对于XML数据来说，每行大约需要1Kb。我粗略计算的经验法则是每页使用8Kb (有时可以根据您的dbms进行调整)，因此每页只有8行。

此外，这也意味着使用像WHERE Description = 'Day'这样的子句查询行要困难得多。(不过，这在您的应用程序中可能无关紧要。)此外，使用现有的结构，如果需要，可以按"Language“对表进行分区。

向原始表添加新列似乎引入了多值依赖关系，这违反了4NF。(Language->>Description)但是，如果您可以将其建模为复合属性，您就可以消除这种依赖关系。

复合属性：复合属性是一种具有内部结构的属性，dbms可以a)完全忽略它，或者b)提供函数和运算符，以便用户可以操作这些部分。最常见的例子是"date“类型的列。日期有内部结构--年、月、日。它们具有内部多值依赖关系。但是dbms提供了函数和运算符，以便在您需要时获取它们。

您的dbms可能会使用复合、复合、用户定义、类型、列和属性等词的组合来描述此功能。

如果您的dbms支持用户定义的类型，则可以为特定于区域设置的单词创建类型，并在表中使用该类型。

但在任何情况下，这不应该是一个意见问题。您应该能够在一个下午或一天内测试具有代理键的5NF方法、没有代理键的5NF方法、具有复合类型或用户定义类型的5NF方法以及XML。然后再花一个下午来确保你的索引和查询做得很好，这样性能差异就不会仅仅是由于错误、匆忙或无知造成的。

最后，权衡最好的性能与维护成本。(并用这些新学到的技能更新你的简历。)