在表格中维护3个小柱或1个大柱是否更好？

Question

三个小一些列[数（1）] >>

OptionA | 0/1 
OptionB | 0/1 
OptionC | 0/1 

或一个较大的字符串列[VARCHAR2（29）] >>

Options | OptionA=0/1|OptionB=0/1|OptionC=0/1 

我不知道的方式数据库处理表格，但我认为将三列保存为Number（1）要比Varchar2（29）的一列好！

CNC中

让我解释的情况多一点：我在一个共同的框架内工作

在所有呼入/呼出请求/响应被跟踪，这些相互作用可以被引导到DB /文件/ JMS;现在所有的配置正在从具有对应于所述输出类型的列的表中加载，我目前使用“DB = 1 | FILE = 1 | JMS = 0”作为该列的值，以便以后如果任何人都想为他们的模块添加这个，他们可以很容易地理解发生了什么，在我的代码中，我写了一个简单的逻辑，用“|”分隔字符串。然后我用的是异或操作者使用开关的情况下选择之间切换..

一切都已经完成了，但我不喜欢一个大柱的想法是比三小+更好的将取消拆分字符串我正在做。

CNC中

我终于得到了澄清，有可能是因为我们不得不添加更多选项的情况;在这种情况下，如果我们明智地添加数据列，将会导致修改表+更改实体+添加更多（如果全是）;另一方面，我最终以一种简单的智能逻辑在枚举之间切换，这样一来，我需要修改枚举&添加一个新的处理程序为新选项&那么我们是好去。

Answer 1

使用单一的列来存储数据的多个部分，可能是你可以在数据库最糟糕的事情。

违反第一范式至少存在以下缺点：

1. 更难查询。OptionA = 1 and OptionB = 1 and OptionC = 0与substr(options, 9, 1) = '1' and substr(options, 19, 1) = '1' and substr(options, 19, 1) = '0'。
2. 较不灵活。当你需要添加另一个选项时会发生什么？添加一个新列很容易。添加新格式可能会导致旧查询混乱。例如，如果有人试图用substr(options, -1, 1)读取OptionC。 （虽然这是一个很好的理由要使用第三个选项 - 一个单独的表）
3. 没有类型安全。这可能是一个非常微妙和棘手的问题。假设你写substr(options, 9, 1) = 1而不是substr(options, 9, 1) = '1'。如果有人得到错误的格式，单个值可能会破坏很多查询。或者更糟糕的是，它只是间歇性地崩溃了少量的查询，因为访问路径不断变化。 （虽然您可以通过检查约束来防止此问题。）
4. 查询速度较慢。通常，表达式或条件中完成的工作量并不是查询的重要成本。但增加大量不必要的字符串操作可能会有所作为。
5. 较少优化。如果Oracle能够理解您的数据，则只能构建高效的查询计划。例如，假设OptionA在99.9％的时间内为“0”。当您过滤OptionA = 0时，Oracle可以使用直方图对返回的行数进行非常准确的预测。但是对于substr(options, 9, 1) = '1'，你只会得到一个猜测。如果您使用此列进行复杂查询，则可能会花费大量时间来“修复”基数估计值。 （虽然也许表达式统计可以帮助这个吗？）

有时反正规化是一个好主意。例如，如果您有TB级的数据，并且压缩了表格，则单列可能会占用较少的空间。 （但是如果你想节省空间，为什么不用像“000”这样的格式呢？）。

如果真的有一个很好的理由，它肯定需要记录。也许在专栏中添加评论。

Answer 2

一开始，如果我正确读你的问题，你希望每个选项只有两个可能值之一，正确吗？

如果是这样，那么您会：

• 具有用于每个选项
• 具有options列，它是1和0的，一个数字为例如每个选项的字符串单独整数（或布尔）柱“001”
• 使用“选项”列，它是一个整数，并使用一个比特值的每个选项，例如optionA ==选项& 1，optionB ==选项& 2等
• 某些数据库具有你可以使用一个位向量数据类型。对于mysql，有BIT数据类型，它可以存储长达64位的位串。

这些代码的复杂性和效率之间会有一个折衷。问问自己，通过采用这些选项中的哪一个，可以节省多少时间或存储空间？又有多少你时间将被保存？

Answer 3

在这种情况下，3列的方法是一个我建议，这不仅让事情在提取数据方面简单，但你应该永远希望你能设定值对所有3列，而不是局限于一个VarChar2字段。如果您选择单列VarChar2，那么使用substr命令或其他变体提取所需的信息相当简单，虽然这对于Oracle数据库来说并不繁重，但它实际上会将额外的工作放在服务器上这是没有必要的。