NCHAR (1) против БИТ

Question

Я работаю по схеме рефакторинга базы данных (SQL Server 2008) и собираю аргументы, чтобы изменить NCHAR(1) столбцы (которые сохраняют Y|N значения) на BIT. Все понимают, что это необходимо, и не знают, почему это происходит, но это изменение влияет на производственную базу данных, поэтому требуются веские аргументы. В таблице хранится адресный каталог (до 1 м записей).

Первый аргумент, который я нашел - каждое поле nchar занимает 2 байта, каждое 8 битовое поле - 1 байт (следующие 8 - дополнительный 1 байт).

Что дальше? Может быть, некоторые проблемы с производительностью индексов?

Answer 1

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

Проверяли ли вы, что использование nchar (1) вредно?производительность, или вы попали в ловушку преждевременной оптимизации?Здесь вы говорите только о 1 миллионе записей.

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

Answer 2

Одной из распространенных причин поиска NCHAR (1) вместо битов является то, что Oracle не поддерживает битовый тип.Если у вас был разработчик Oracle или Oracle, или база данных, которая раньше работала в Oracle, вы увидите это очень часто.В Sql Server это действительно не нужно.

Однако я обнаружил, что в большинстве мест, где у меня есть битовое поле (или NCHAR (1) в Oracle), то, что я действительно хочу, это дата-время, которое указывает не столько значениефлага, но именно тогда, когда это стало правдой.Это не всегда так, но когда я вспоминаю старый код, который я написал, я думаю, что 4 раза из 5 я использовал битовое поле, я должен был использовать дату и время.

Answer 3

Битовое поле помогает вашей логике, автоматически применяя неявное бизнес-правило (т. Е. Этот столбец может содержать только «Y» или «N»).Если вы применяете это правило программно, вы можете сэкономить, исключив эти накладные расходы.Индексирование битового столбца само по себе имеет небольшое значение из-за низкой мощности, но оно может быть полезно как часть составного индекса.Char (1) в SQL Server

Должен ли я индексировать битовое поле в SQL Server?

Answer 4

Создайте битовое поле, добавьте вычисляемый столбец, который сейчас эмулирует nchar (1).

Что не использовать nchar:

• Y против y против некоторых unicode Y
• Затраты на проверку Y или N
• Не является «истинным» или «ложным» (например, не сопоставляется напрямую с логическим значением .net)
• Y и N - английский. Ja / Nein, Oui / Non и т. Д.

Вы не должны индексировать это в любом случае, так что это сводится к эффективному хранению и использованию. бит

• меньше
• тип данных безопасен (например, ПРОВЕРКА не требуется)
• сопоставляется с клиентом, что означает непосредственно
• независимо от региона

Сказав это, мы используем поле «WhenInactive» smalldatetime вместо поля «IsActive». NULL = активный.

Answer 5

Если вы используете LINQ2SQL или Entity Framework, столбец BIT преобразуется в bool, а NCHAR(1) - в string.

.

Answer 6

Использовать бит:

• Логическое представление / выразительность намерения - поскольку булевы состояния не всегда могут быть выражены последовательно как Yes or No, что будет означать, что вам нужно либо быть непоследовательным в битах моделирования, либо неинтуитивным, например True/False (T/F), On/Off (?O/F), Open/Closed(O/C) и т. Д.

• Ссылочная целостность - ненулевой бит может быть ограничен только 0 or 1. Если вы не добавите ограничения, ваш *char(1) может быть Y, N, X или ☺.

• Биты могут быть упакованы , поэтому может иметь меньший объем хранения.

• Re: Производительность: Индексирование битовых (или CHAR-столбцов с несколькими состояниями) обычно является пустой тратой, если только в данных нет высокой селективности 0 или 1. В этом случае неплохо было бы использовать отфильтрованный индекс для выборочного значения.

(перенесено с удаленный ответ здесь )

Answer 7

Широко ли используется поле в запросах Where fld = 'Y'?

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

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

Answer 8

У меня было несколько случаев, когда мы хотели битовое поле, но не могли точно знать, что никогда не будет необходимости в третьем или четвертом значении в этом поле. Поэтому мы структурировали его как строковое поле, содержащее Y или N. Конечно, мы делали это только в очень уникальных ситуациях.