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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

Это ужасно распространено в файлах мэйнфреймов, COBOL и т.д.

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

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

По-видимому, бит-столбцы не являются хорошей идеей в MySQL.

Ответ 9

Вероятно, они использовались для использования Oracle и не правильно считывали доступные типы данных для SQL Server. Я сам в такой ситуации (и поле Y/N меня заводит).

Ответ 10

Я видел хуже...

Один O/R-сопоставитель Мне приходилось работать с использованными "истинными" и "ложными", поскольку их можно было бы чисто вставлять в Java booleans.

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

Ответ 11

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

Ответ 12

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