Char (4) против int как столбец StatusID / StatusCode в таблице

Question

Мне нужен столбец состояния, который будет иметь около десятка возможных значений. Есть ли причина, по которой я должен выбрать int (StatusID) вместо char (4) (StatusCode)? Поскольку сервер sql не поддерживает именованные константы, char используется гораздо более наглядно, чем int, когда используется в хранимых процедурах и в представлениях в качестве констант. Чтобы уточнить, я бы все равно использовал таблицу поиска в любом случае. Поскольку мне понадобится более описательный текст для пользовательского интерфейса. Поэтому это решение помогает мне как разработчику, когда я поддерживаю хранимые процедуры и представления.

Прямо сейчас я склоняюсь к полукоксу (4). Тем более, что проектирование представлений в SQL Server Management Studio не позволяет мне добавлять комментарии (я знаю, что это возможно добавить в редакторе сценариев, но реально я буду использовать View Designer гораздо чаще, особенно если представление тривиально). StateCODE = 'NEW' гораздо лучше читается, чем StateID = 1000. Я предполагаю, что вопрос в том, будут ли случаи, когда char (4) проблематичен, и, поскольку база данных довольно мала, меня не слишком беспокоит небольшое снижение производительности (например, использование TinyInt по сравнению с int), но я больше боюсь проблем с поддержкой кода .

Answer 1

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

Но для операторов и конечных пользователей наличие описательного кода состояния может быть благословением. И это даже не обязательно должно быть char (4), вы можете сделать его varchar (20). Это позволяет им выполнять запросы без объединений и более просто проверять базу данных.

В конце концов, я думаю, что организация char (20) будет работать более гладко и пойдет домой раньше в пятницу. Но у организации int есть лучшая абстракция базы данных, и они могут наслаждаться метапрограммированием в пятницу вечером (или на форумах).

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

Answer 2

Есть много «за» и «против» каждого метода. Я уверен, что другие аргументы придут в пользу использования char (4). Мои причины выбора типа int вместо char:

1. Я всегда использую справочные таблицы. Они позволяют сохранять и легко проверять контрольный журнал стоимости. Например, если один из ваших кодов состояния - «MING», и принято бизнес-решение изменить его с «MING» на «MONG» с определенной даты, моя таблица поиска обрабатывает это.

2. Меньший индекс - если вам нужно проиндексировать этот столбец, он будет тоньше.

3. Расширяемость - хорошо, я придумал это слово, но если вам нужно, например, перейти от 4 символов к 5 символам, справочная таблица была бы благословением.

4. Описания: Мы используем здесь много TLA, и как только вы узнаете, что они из себя представляют, это замечательно, но если бы я дал бизнес-пользователю отчет, в котором говорилось: «GDA's 2007 1001», они не обязательно прут, что GDA = Добрый мертвец по прибытии. С помощью таблицы поиска я могу добавить это описание.

5. Рекомендация: не могу найти ссылку, но это может быть то, что я прочитал в статье K.Tripp. Постарайтесь, чтобы ваши кластерные первичные ключи увеличивали целые числа для оптимизации индекса.

Конечно, если вы абсолютно уверены, что вам никогда не понадобится больше, чем горстка из 4 символов, нет никаких причин, чтобы не стучать в таблицу.

Answer 3

Место, где я столкнулся с этим вариантом использования, - это столбцы, которые будут отображаться на вещи, для которых я обычно использую Enum при программировании. Храните ли вы целочисленное значение Enum или имя Enum в столбце базы данных? Честно говоря, я сделал это в обе стороны. Обычно я спрашиваю себя, будет ли база данных использоваться вне приложения, которое я создаю. Если так, я выберу удобочитаемый формат для хранения в базе данных. Если нет, тогда я выберу целочисленное значение, поскольку оно экономит немного времени при восстановлении (это просто приведение вместо операции разбора) Enum в коде.

Answer 4

Неопределенность сопоставления - одна из причин, по которой нужно сказать «нет» символу 4: ABcD = abCD = äBCd?

Если у вас есть 12 возможных значений, почему не tinyint / byte и таблица Status? Если вам нужно сохранить состояние для 10 миллионов строк, 3 байта будут разными, и сравнение параметров сортировки и строк сложится.

Answer 5

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

Answer 6

Если вы имеете дело с огромными объемами данных и высокой пропускной способностью, то smallint или tinyint могут обеспечить лучшую производительность и меньшую площадь жесткого диска. Если данные в вашем приложении часто просматриваются непосредственно через приложения, такие как Access или Cognos, тогда ваши деловые люди, вероятно, оценят описательные значения. Я знаю, что когда я анализирую данные как часть своей роли разработчика баз данных, я устаю от объединения многих таблиц поиска, потому что не могу вспомнить, если 1 = Foo и 2 = Bar или 1 = Bar и 2 = Foo.

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

Answer 7

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

Answer 8

Вы также можете использовать tinyint поверх int