Зачем использовать «Y» / «N» вместо битового поля в Microsoft SQL Server?

Question

Я работаю над приложением, разработанным другим мобом, и меня смущает использование поля char вместо бита для всех логических столбцов в базе данных. Он использует «Y» для истины и «N» для ложных (они должны быть в верхнем регистре). Имя самого типа затем связывается с каким-то непонятным именем, например ybln .

Это очень неприятно работать по многим причинам, не в последнюю очередь из-за того, что это выглядит просто эстетически неприятно.

Но, может быть, это я глупый - зачем кому-то это делать? Это проблема совместимости базы данных или какой-то шаблон проектирования, о котором я не знаю?

Может ли кто-нибудь просветить меня?

Answer 1

Я видел эту практику в старых схемах баз данных довольно часто. Одно из преимуществ, которое я видел, заключается в том, что использование полей CHAR (1) обеспечивает поддержку более чем вариантов Y / N, таких как «Да», «Нет», «Возможно».

Другие авторы упоминали, что Oracle мог быть использован. Схема, на которую я ссылался, фактически была развернута в Oracle и SQL Server. Использование типов данных ограничено общим подмножеством, доступным на обеих платформах.

Они действительно расходились в нескольких местах между Oracle и SQL Server, но по большей части они использовали общую схему для баз данных, чтобы минимизировать работу по разработке, необходимую для поддержки обеих БД.

Answer 2

Добро пожаловать в Браунфилд. Вы унаследовали приложение, разработанное старшеклассниками. Это не шаблон проектирования (по крайней мере, шаблон проектирования с чем-то удачным), это пережиток кодеров, которые рубят зубы в базах данных с ограниченными типами данных. Если не считать рефакторинга БД и большого количества кода, стисните зубы и проделайте свой путь через него (и следите за своим делом)!

Answer 3

Другие платформы (например, Oracle) не имеют битового типа SQL. В этом случае это выбор между NUMBER (1) и односимвольным полем. Может быть, они начали на другой платформе или хотели кросс-платформенной совместимости.

Answer 4

Мне не нравится поле Y / N char (1) в качестве замены для битового столбца, но в таблице есть один существенный недостаток битового поля: вы не можете создать индекс для битового столбца или включение его в составной индекс (по крайней мере, в SQL Server 2000).

Конечно, вы могли бы обсудить, понадобится ли вам когда-либо такой индекс. Смотрите этот запрос на форуме SQL Server .

Answer 5

Это очень часто встречается в файлах мэйнфреймов, COBOL и т. Д.

Если у вас есть только один такой столбец в таблице, на практике это не так уж страшно (никаких реальных потерь); В конце концов, SQL Server не позволит вам сказать натуральное WHERE BooleanColumn, вы должны сказать WHERE BitColumn = 1 и IF @BitFlag = 1 вместо гораздо более натурального IF @BooleanFlag. Если у вас есть несколько битовых столбцов, SQL Server их упакует. Случай Y / N должен быть проблемой, только если используется сортировка с учетом регистра, и для остановки неверных данных всегда есть опция ограничения.

Сказав все это, я лично предпочитаю биты и допускаю NULL s только после тщательного рассмотрения.

Очевидно, битовые столбцы не очень хорошая идея в MySQL .

Answer 6

Возможно, они начали разработку с Microsoft SQl 6.5

.

В то время добавление битового поля в существующую таблицу с данными было королевской болью сзади. Битовые поля не могут быть нулевыми, поэтому единственный способ добавить одно в существующую таблицу - создать временную таблицу со всеми существующими полями целевой таблицы плюс битовое поле, а затем скопировать данные, заполнив битовое поле. со значением по умолчанию. Затем вам пришлось удалить исходную таблицу и переименовать временную таблицу в исходное имя. Добавьте несколько внешних ключевых отношений, и у вас есть длинный сценарий для написания.

Сказав это, всегда были сторонние инструменты, чтобы помочь с процессом. Если предыдущий разработчик решил использовать символьные поля вместо битовых полей, то в двух словах причина, вероятно, была лень.

Answer 7

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

Я также представляю, что в большинстве случаев разница между хранилищем BIT и CHAR (1) незначительна (это CHAR - NCHAR? Хранит ли он 16-битный, 24-битный или 32-битный символ Юникода?

Answer 8

Причины следующие (кстати, они не являются вескими причинами):

1) Y / N может быстро стать «X» (для неизвестного), «L» (для вероятного) и т. Д. - Я имею в виду, что лично работал с программистами, которые так привыкли не собирать правильно требует, чтобы они только начали с Y / N как своего рода «флаги» с суеверием, которое может потребоваться расширить (до которого они должны использовать int в качестве идентификатора состояния).

2) «Производительность» - но, как было упомянуто выше, индексы SQL исключаются, если они недостаточно «избирательны» ... поле, имеющее только 2 возможных значения, никогда не будет использовать этот индекс.

3) Ленивость. - Иногда разработчики хотят выводить напрямую на какой-либо визуальный дисплей с буквой «Y» или «N» для удобства чтения, и они не хотят сами конвертировать его:)

Есть все 3 плохих причины, которые я слышал / видел раньше.

Answer 9

У меня нет сильных чувств в любом случае. Я не вижу большой пользы в том, чтобы делать это так, как нужно. Я философски знаю, что битовые поля лучше хранить. Моя реальность такова, что у меня очень мало баз данных, которые содержат множество логических полей в одной записи. Если бы у меня было много, я бы точно хотел битовые поля. Если у вас есть только несколько, я не думаю, что это имеет значение. В настоящее время я работаю с базами данных Oracle и SQL-серверов, и я начал с базы данных IDMS от Cullinet (1980), где мы упаковывали все виды данных в записи и беспокоились о битах и ​​байтах. Хотя я все еще беспокоюсь о размере данных, я давно перестал беспокоиться о нескольких битах.

Answer 10

Иногда такие причуды больше связаны с приложением, чем с базой данных. Например, обработка логических значений между PHP и MySQL является хитом и приводит к неинтуитивному коду. Использование полей CHAR (1), а 'Y' и 'N' делает код более понятным.