添加信息、xml 列或新表？答案

【问题标题】：Adding information, xml column or new table?添加信息、xml 列或新表？
【发布时间】：2013-02-12 15:04:19
【问题描述】：

我们想扩展我们的数据库以创建多语言支持，但我们不确定如何做到这一点。我们的数据库如下所示：

ID - 名称 - 描述 - （很多不相关的列）

选项1是在表中添加一个xml列，在这个列中我们可以像这样存储我们需要的信息：

<translation>
    <language value=’en’>
        <Name value=’’>
        <Description value=’’>
    </language>
    <language value=’fr’>
        <Name value=’’>
        <Description value=’’>
    </language>
</translation>

诀窍和好处是，当我删除行时，我也删除了翻译。

方案2是增加一个额外的表，创建一个表来存储信息很容易，但是在获取信息时需要内部连接，并且在删除原始行时更努力地删除行。

在这种情况下，首选的选项是什么？或者有其他好的解决方案吗？

【问题讨论】：

如果你有另一个表，删除行并不费力，如果你使用外键和引用动作触发器ON DELETE CASCADE，当你从主表中删除行时，它会删除附加表中的行。这可能是一个过于主观的问题，但我会说使用附加表，这是关系数据库的全部要点，您可以在附加表上使用索引、约束等，而不能在 XML 列上使用。如果您需要 XML 格式的数据，将其转换为 XML 并不难。
您也可以使用NVARCHAR2数据类型将多语言数据存储在单列中

标签： sql database-design

【解决方案1】：

我建议使用“关系”方法，即单独的翻译表。考虑这样做：

这个模型有一些不错的特性：

为每个多语言表创建一个单独的翻译表。这样，您就可以使用适用于该特定表格的字段，并且翻译不会“错误连接”到错误的表格。
与 XML 不同，LANGUAGE 表和关联的 FOREIGN KEY 的存在确保了不存在语言的翻译不能存在。
ON DELETE CASCADE 引用操作将确保在删除语言时不会留下“孤立”翻译，这与 XML 不同。
虽然 XML 在更简单的情况下可能更快，但我怀疑 JOIN 在语言数量增加时更具可扩展性。¹ 在任何情况下，衡量差异并决定如果它足够重要，你自己。
NAME 和DESCRIPTION 等单独的字段可能更容易索引。对于 XML，您可能需要一个对 XML 有特殊支持的 DBMS，或者可能需要某种全文索引。
NAME 和DESCRIPTION 等字段可能只是常规的VARCHAR。 OTOH，将它们放在一起可能会生成对于常规 VARCHAR 而言太大的 XML，从而迫使您使用 CLOB/BLOB，这可能会带来其自身的性能问题。
如果您的 DBMS 支持集群（见下文），则整个转换表可以存储在单个 B-Tree 中。 XML 有很多冗余数据（开始和结束标签），可能使它比 B-Tree 更大且对缓存更不友好（即使我们计算了所有相关的开销）。

您会注意到上面的模型使用identifying relationships 并且生成的PK：{LANGUAGE_ID, TABLEx_ID} 可用于clustering（因此属于同一语言的翻译在物理上紧密地存储在数据库中)。只要您有少数主要（或“热”）语言，这应该没问题 - 缓存是在数据库页面级别完成的，因此避免将“热”和“冷”数据混合在同一个页面避免缓存“冷”数据（并使缓存“更小”）。

OTOH，如果您经常需要查询多种语言，请考虑将集群键顺序翻转为：{TABLEx_ID, LANGUAGE_ID}，以便同一行的所有翻译在物理上紧密地存储在数据库中。一旦您检索到一个翻译，同一行的其他翻译可能已经被缓存。或者，如果您想在单个查询中提取多个翻译，则可以使用更少的 I/O。

¹ 我们可以只加入所需语言的翻译。使用 XML，您必须先加载（并解析）整个 XML，然后再决定只使用与所需语言相关的一小部分。每当您添加新语言（以及与 XML 相关的翻译）时，即使您很少使用新语言，它也会减慢现有行的处理速度。

【讨论】：