Почему это плохо для использования булевых флагов в базах данных? И что должно использоваться вместо этого?
Я прочитывал некоторые руководства по оптимизации базы данных и лучшим практикам, и многие из них предлагают не использовать булевы флаги вообще в схеме DB (исключая http://forge.mysql.com/wiki/Top10SQLPerformanceTips). Однако они никогда не обеспечивают причины относительно того, почему это плохо. Действительно ли это - проблема производительности? трудно индексировать или запросить правильно?
Кроме того, если булевы флаги плохи, что необходимо использовать для хранения булевых значений в базе данных? Лучше сохранить булевы флаги как целое число и использовать битовую маску? Это кажется, что было бы менее читаемо.
4 ответа
Я не думаю, что это плохо, и я никогда не видел причины, заявленной для этого. Возможно, некоторые старые механизмы баз данных не могут эффективно хранить их, но современные это делают. Как вы говорите, использование логических значений намного удобнее, чем битовые маски. См. Этот вопрос для аналогичного обсуждения: Полезно ли добавление битовой маски ко всем таблицам в базе данных?
Единственная причина, о которой я мог подумать, - это случаи, когда вы должны использовать ENUM вместо этого. Конечно, сейчас вам нужны только true и false, но если вы захотите добавить что-то еще позже, вам нужно будет выполнить операцию ALTER TABLE, что может оказаться очень дорогостоящим.
Мое предположение: переносимость вашего дизайна.
например.
Microsoft Access обрабатывает логическое значение как -1 как истина или 0 как ложь, в то время как другие базы данных могут обрабатывать логическое значение иначе.
В MySQL (версия 4+) с другой стороны, нулевое значение считается ложным. Ненулевые значения считаются истинными.
Конечно, практика работы с базами данных имеет мало общего с теорией, я все же попытаюсь объяснить теоретически. Таблицы являются конечными отношениями.Каждое отношение является расширением предиката. Логический атрибут — это неправильное название предиката.