Почему столбцы типа BOOLEAN проблематичны в дизайне реляционных баз данных?

Я работаю в основном с Oracle в течение последних нескольких лет и довольно привык видеть одиночные столбцы символов varchar, используемые в качестве логических значений.

Я также могу видеть (для ответов на переполнение стека), предлагаемым типом для MySQL является TINYINT.

Теперь я взял мой маленький проект - используя DerbyDB, и он поддерживает столбцы BOOLEAN, но только после версии 10 или около того.

Итак, вопрос в том, почему так сложно включить столбец BOOLEAN при разработке реляционной базы данных? Я что-то упускаю, или это просто толкает список дел как несущественный, поскольку вы можете использовать другой тип столбца между тем?

Ответ 1

Том Ките в значительной степени повторяет ваше последнее предложение в этой записи в блоге:

"Это просто не тот тип, который у нас есть - я могу сказать больше и не меньше. ANSI не имеет его - многие базы данных не имеют его (мы, конечно, не в одиночестве). В великой схеме вещей - я бы сказал, Приоризация этого довольно" низкая" (это мое мнение).

Он говорит с точки зрения Oracle, но применим к любой реляционной СУБД.

Ответ 2

В случае с Derby, в частности, ответ представляет собой немного странную историю: Derby, база данных с открытым исходным кодом, когда-то называлась Cloudscape и была запатентованным продуктом. В то время он полностью поддерживал BOOLEAN.

Впоследствии Cloudscape был приобретен Informix, который был приобретен IBM, и IBM Engineering решила сделать Derby совместимым с DB2. Причиной этого было то, что если бы две базы данных были совместимы, пользователям было бы проще переносить свои приложения между базами данных Derby и базами данных DB2. Однако технический персонал не удалял функции, не совместимые с DB2, из Derby, они просто отключили их в грамматике SQL, оставив большую часть реализации на месте.

Впоследствии IBM открыла Cloudscape для Apache Software Foundation, назвав ее Derby. Сообщество с открытым исходным кодом, больше не связанное требованием полной совместимости Derby с DB2, решило оживить поддержку типа данных BOOLEAN. И поэтому Derby теперь имеет поддержку типа BOOLEAN.

Ответ 3

PostgreSQL имеет поддержку boolean столько, сколько я могу думать.

Самый старый онлайн-документ, который я могу найти, для версии 6.3 выпущен в 1998-03-01. Они упоминают булевский тип:

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

В позже docs они упоминают SQL99 как стандарт, который они следуют.

Так как SQL99, похоже, упоминает этот тип, я бы предположил, что многие DBs поддерживали этот тип довольно хорошо до 1999 года.

Ответ 4

Я не знаю, как я его не разработал, но я предполагаю, что, поскольку RDBMS описывают и запоминают множество вещей, логические поля не нужны, потому что они также будут обозначать то, что находится в наборе, но они посторонними, поскольку членство в наборах будет получено из фактических данных или структуры базы данных.

В качестве примера возьмите булевский столбец для ролей, предоставляемых сотрудникам, где они либо менеджеры, либо они не являются. Вы можете использовать булевский столбец, чтобы описать это, но то, что вам нужно сделать, это либо иметь таблицу для менеджеров, либо таблицу для не-менеджеров, либо (и это было бы более гибким и, вероятно, более управляемым) up ", которая предоставляет роли (как один текстовый столбец) и ключ, который затем ссылается (внешний ключ) в таблице сотрудников.

Я думаю, что я должен добавить, что в большинстве случаев вы видите логическое поле в таблице, это запах кода, так как он ~~может~~ может поражать производительность - для использования логического выражения в предложении where будет вызываться таблица сканировать и сделать индексы на столе довольно бессмысленными (но см. комментарии для дальнейшего обсуждения этого вопроса). Я бы рискнул еще догадываться о том, что булевы типы данных были добавлены к большинству СУБД для использования в их процедурных языковых расширениях (T-SQL, PLSQL), чтобы помочь с нечетным условным утверждением, которое требуется.