在 sql 中包含行或列是否更高效？答案

【问题标题】：Is it more performant to have rows or columns in sql?在 sql 中包含行或列是否更高效？
【发布时间】：2012-04-04 22:07:06
【问题描述】：

如果我必须保存许多相关的并且可能以不同语言划分的字符串：最好的方法是什么？

我认为我有以下选择。选项 1 和 3 对我来说是最明确的解决方案。它们有更多的列，但会导致更少的行。

选项 2 和 4 是最灵活的选项（我可以在不更改数据库的情况下动态添加新的 string_x）。它们只有三列，但会产生很多行。

选项 5 会产生很多表。

选项 1：

id | string_1 | string_2 | string_3 | string_4 | ... | string_n | lang

选项 2 *（其中名称为 string_1 或 string_2 等）*

id | name | lang

选项 3

id | string_1 | string_2 | string_3 | string_4 | ... | string_n
id | lang     | stringid

选项 4

id | lang | stringid
id | name

选项 5

id | string_1 | lang
id | string_2 | lang
id | ...      |lang

如果感兴趣的话，我正在使用它来存储多个视图（一行视图、两行、长描述等）的预缓存 html 值。

【问题讨论】：

【解决方案1】：

不建议使用选项 1 和 3，因为您最终会在字段名称中使用语言（即数据）。如果要添加另一种语言，则必须更改数据库设计。

不推荐使用选项 5，因为您最终会在表名中使用字符串标识符（即数据）。如果要添加另一个字符串，则必须更改数据库设计。

选项 2 或 4 可以正常工作。选项 4 更加规范化，因为您没有重复的字符串名称，但如果您直接在表格视图中输入值，选项 2 可能更容易使用。

表中有很多行不是问题，这就是构建数据库系统的目的。

【讨论】：

“选项 4 更加规范化”——根据问题中的信息，看不到任何人如何能说出任何表格的正常形式。
@onedaywhen：选项 2 的字符串名称为每种语言重复。
那么我会选择选项 4。谢谢你。我想最好让字符串表引用语言表，因为如果我可能有其他本地化的数据集，我可以重用语言表。
不知道选项2的key是什么，怎么能说它满足什么范式呢？如果你不能说这个（或任何其他表格）是什么正常形式，你怎么能说“选项 4 更规范化”？当然是反问：没有突出的事实，谁也说不出来。
@onedaywhen：我没有声称知道任何选项属于哪种范式，只是选项 4 比选项 2 更规范化。

【解决方案2】：

虽然我不必专门处理多语言界面，如果这就是它的全部目的，是翻译，我会选择选项 1，但交换了，类似

id 英语法语德语西班牙语等...

因此，您基本上将有一个主列（例如英语）作为始终填充的“主要”单词，然后在可用时填充其他语言列。这样，您可以继续添加尽可能多的“单词” " 根据您的需要，如果它们被填充到所有不同的语言中，那就这样吧......如果没有，您仍然有一个可以使用的“主要”值。

【讨论】：

【解决方案3】：

这取决于很多其他事情。首先，可以有多少个字符串？可以有多少种语言？为简化起见，假设其中任何一个数字大于 5，则选项 1 和 3 不可行。

在我继续之前，您绝对应该考虑在数据库之外实现多语言功能。在 PHP 中，您可以使用 Gettext 并将您的翻译数据放在平面文件中。出于多种原因，这是一个更好的主意，主要是性能和外部翻译的易用性。

如果您绝对必须在数据库中执行此操作，那么您应该使用类似于以下的表结构：

id | string | language

一个示例条目是：

welcome_message | Hello, World! | english

我认为您已在 选项 2 中进行了描述。澄清一下，根据不同语言和不同字符串的数量，您应该使用具有固定数量字段的单个表。

【讨论】：

【解决方案4】：

如果您只支持几种语言，您还可以考虑一种架构，其中每种语言都是自己的列：

ID    EN    ES    FR   Etc...

这没有你的选项 4 标准化，但它很容易使用。我们已经建立了这样的数据库翻译。在我们开发代码时，我们创建字符串资源填充英文文本。稍后，翻译人员填写他们的语言字符串。

【讨论】：