为什么BOOLEAN类型列在关系数据库设计中存在问题？

Question

过去几年我一直主要使用Oracle，并且习惯于将单字符varchar列用作布尔值。

我也可以看到（每个堆栈溢出答案），MySQL的建议类型是TINYINT。

现在我接受了我的小方案项目 - 使用DerbyDB，它支持BOOLEAN列，但直到10版左右才开始。

所以，问题是，为什么在设计关系数据库时合并BOOLEAN列如此困难？我是否遗漏了某些内容，或者只是将其下放到待办事项列表中并不重要，因为您可以同时使用其他列类型？

Answer 1

就Derby而言，具体而言，答案有点奇怪：开源数据库Derby曾经被称为Cloudscape，是一种专有产品。那时，它完全支持BOOLEAN。

随后，Cloudscape被IBM收购的Informix收购，IBM工程师决定让Derby与DB2兼容。原因在于，如果两个数据库兼容，则用户可以更轻松地在Derby数据库和DB2数据库之间迁移其应用程序。但是，工程人员没有从Derby中删除非DB2兼容的功能，他们只是在SQL语法中禁用它们，而大多数实现都已就绪。

随后，IBM向Apache Software Foundation开源Cloudscape，命名为Derby。开源社区不再受Derby与DB2完全兼容的要求的约束，决定恢复BOOLEAN数据类型支持。因此，Derby现在支持BOOLEAN数据类型。

Answer 2

Tom Kyte几乎回应了你的最后一句in this blog entry：

  

“它不是我们拥有的类型 - 我可以说不多也不少.ANSI   没有它 - 许多数据库没有它（我们当然不是   单独）。在宏伟的计划中 - 我会说   对此进行预防非常“低”（这是我的意见）。“

他是从Oracle的角度讲，但它适用于任何关系型RDBMS。

Answer 3

只要我能想到，PostgreSQL确实支持boolean。

我能找到的最老的在线文档是针对版本6.3发布的1998-03-01。他们提到了布尔类型：

http://www.postgresql.org/docs/6.3/static/c0805.htm

在later docs中，他们提到SQL99作为他们遵循的标准。

由于SQL99似乎提到了这种类型，我认为，许多数据库在1999年之前确实支持这种类型。

Answer 4

我没有知道，因为我没有设计过，但我的猜测是，因为RDBMS是关于描述和存储事物的集合，所以不需要布尔字段，因为它们也会表示集合中的内容，但它们是无关紧要的，因为集合的成员资格将从数据库的实际数据或结构中派生。

作为一个例子，对于给员工的角色，他们是管理者，或者他们不是，给一个布尔列。您可以使用布尔列来描述这一点，但应该做的是要么有管理员表，要么有非经理人表，或者（这会更灵活，可能更易于管理）方式）创建一个额外的“查找”表，该表提供角色（作为单个文本列）和随后在employees表中引用的键（外键）。

---

我想我应该补充说，大多数时候你在表中看到一个布尔字段，这是代码味道，因为它将 可能命中性能 - 使用布尔值where子句将调用表扫描并使表上的索引毫无意义（但请参阅注释以进一步讨论此内容）。我想再次猜测布尔数据类型已被添加到大多数RDBMS中，以便在其过程语言扩展（T-SQL，PLSQL）中使用，以帮助处理所需的奇怪条件语句。