Является ли тип данных CHAR в SQL устаревшим? Когда вы используете это?

Question

Название в значительной степени обрамляет вопрос. Я не использовал CHAR годами. Сейчас я занимаюсь реверс-инжинирингом базы данных, в которой есть CHAR, для первичных ключей, кодов и т. Д. Как насчет столбца CHAR (30)?

Edit: Таким образом, по общему мнению, CHAR идеально подходит для определенных вещей. Я, однако, думаю, что вы можете разработать схему базы данных, которая не нуждается в «этих определенных вещах», таким образом, не требуя строк фиксированной длины. С битовым, uniqueidentifier, varchar и текстовыми типами кажется, что в хорошо нормализованной схеме вы получаете определенную элегантность, которую вы не получаете, когда используете кодированные строковые значения. Мышление в фиксированной длине, без обид, похоже, является пережитком мэйнфреймов (я однажды выучил RPG II). Я считаю, что это устарело, и я не услышал убедительных аргументов от вас, утверждающих обратное.

Answer 1

Я использую char (n) для кодов, varchar (m) для описаний. Char (n), по-видимому, приводит к повышению производительности, поскольку данные не должны перемещаться при изменении размера содержимого.

Answer 2

Если характер данных определяет длину поля, я использую CHAR. В противном случае VARCHAR.

Answer 3

CHAR-ы все еще быстрее обрабатываются, чем VARCHAR-ы в СУБД, которые я хорошо знаю. Их фиксированный размер учитывает оптимизации, которые невозможны с VARCHAR. Кроме того, требования к хранилищу для CHARS несколько меньше, поскольку не нужно хранить длину, при условии, что большинству строк необходимо заполнить столбец CHAR полностью или почти полностью.

Это меньше воздействия (в процентах) с CHAR (30), чем CHAR (4).

Что касается использования, я склонен использовать CHAR, когда либо:

• поля, как правило, всегда будут близки или имеют максимальную длину (коды акций, идентификаторы сотрудников и т. Д.); или
• длина короткая (менее 10).

В другом месте я использую VARCHAR.

Answer 4

Я использую CHAR, когда длина значения фиксирована. Например, мы генерируем код или что-то на основе некоторого алгоритма, который возвращает код с определенной фиксированной длиной, скажем, 13.

В остальном я нашел VARCHAR лучше. Еще одна причина использовать VARCHAR заключается в том, что когда вы возвращаете значение обратно в свое приложение, вам не нужно обрезать это значение. В случае CHAR вы получите полную длину столбца независимо от того, заполнено ли значение полностью или нет. Он будет заполнен пробелами, и вы в конечном итоге обрежете каждое значение и забудете, что это приведет к ошибкам.

Answer 5

В PostgreSQL документация гласит, что char() не имеет преимуществ в объеме памяти над varchar(); единственное отличие состоит в том, что он заполнен пробелом до указанной длины.

Сказав это, я все еще использую char(1) или char(3) для односимвольных или трехсимвольных кодов. Я думаю, что ясность из-за типа, определяющего, что должен содержать столбец, обеспечивает ценность, даже если нет никаких преимуществ хранения или производительности. И да, я обычно использую ограничения проверки или ограничения внешнего ключа. Помимо этих случаев, я обычно просто придерживаюсь text, а не varchar(). Опять же, об этом сообщает реализация базы данных, которая автоматически переключается из встроенного в внешнее хранилище, если значение достаточно велико, чего не делают некоторые другие реализации базы данных.

Answer 6

Char не устарел, его следует использовать только в том случае, если длина поля никогда не меняется. В средней базе данных это будет очень мало полей, в основном это кодовое поле, такое как Сокращения состояний, которые представляют собой стандартные 2-символьные поля, если вы используете почтовые индексы. Использование Char, где длина поля является переменной, означает, что будет происходить много обрезки, и это дополнительная, ненужная работа и база данных должна быть реорганизована.