Какой размер выбрать для (n) varchar столбца?

Question

В слегка жарком обсуждении TDWTF возник вопрос о размере столбцов varchar в БД.

Например, возьмите поле, содержащее имя человека (только имя, без фамилии). Это довольно легко увидеть, что это не будет очень долго. У большинства людей есть имена длиной менее 10 символов, и немногие из них старше 20. Если вы сделаете свой столбец, скажем, varchar (50), он определенно будет содержать все имена, с которыми вы когда-либо встречались.

Однако для большинства СУБД не имеет значения по размеру или скорости, делаете ли вы varchar (50) или varchar (255).

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

---

Добавлено: Люди хотят ссылки на утверждение о "нет разницы в размере или скорости". ХОРОШО. Вот они:

Для MSSQL: http://msdn.microsoft.com/en-us/library/ms176089.aspx

Размер хранилища - это фактическая длина введенных данных + 2 байта.

Для MySQL: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

L + 1 байт, если значения столбца требуют 0 - 255 байт, L + 2 байта, если значения могут требовать более 255 байт

Я не могу найти документацию для Oracle, и я не работал с другими СУБД. Но у меня нет причин полагать, что там все по-другому.

Answer 1

Я могу говорить только за Oracle. VARCHAR2 (50) и VARCHAR2 (255) занимают одинаковое количество места и работают одинаково, если вы введете значение «SMITH».

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

В качестве примера. Вы определяете ограничение CHECK для столбца, чтобы значения, которые он может принимать, были только «Y» и «N». Это избавляет ваше приложение от необходимости иметь дело с 'y' и 'n' или даже с '1' и '0'. Проверочное ограничение гарантирует, что ваши данные соответствуют ожидаемым стандартам. Код вашего приложения может затем сделать правильные предположения о природе данных, с которыми он имеет дело.

Определение длины столбца в одной лодке. Вы объявляете что-то VARCHAR2 (10), потому что не хотите, чтобы оно принимало запись 'ABC123ZYX456' (по любой причине!)

В Австралии я определяю столбцы STATE как varchar2 (3), потому что я не хочу, чтобы люди печатали «Новый Южный Уэльс» или «Южная Австралия». Определение столбца в значительной степени заставляет их вводиться как «NSW» и «SA». В этом смысле VARCHAR2 (3) является почти столько же проверочным ограничением, сколько и фактическим указанием ограничения CHECK IN («NSW», «SA», «VIC» и т. Д.).

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

Я тоже не согласен с аргументом о том, что такие вещи лучше всего вставлять в клиентское приложение, потому что их легче там изменить. У вас есть 20 000 человек, использующих приложение, это 20 000 обновлений. У вас есть одна база данных, это одно обновление. Аргумент «проще изменить клиентское приложение», если он истинный, потенциально может означать, что база данных будет восприниматься как гигантское ведро со всей умной логикой, обрабатываемой в клиентском коде. Это большая дискуссия, но, поскольку все СУБД позволяют вам определять ограничения и т. Д. В самой базе данных, совершенно очевидно, что есть хотя бы стоящий случай, когда такая фундаментальная логика принадлежит бэкэнду.

Answer 2

Я слышал, что оптимизатор запросов учитывает длину varchar, хотя я не могу найти ссылку.

Определение длины varchar помогает сообщать намерения.Чем больше определено ограничений, тем надежнее данные.

Answer 3

Одно важное различие заключается в указании произвольно большого предела [например, VARCHAR(2000)] и с использованием типа данных, который не требует ограничения [например, VARCHAR(MAX) или TEXT].

PostgreSQL основывает все свои фиксированные длины VARCHAR s на своем неограниченном типе TEXT и динамически решает для значения , как хранить значение, включая его сохранение вне страницы. Спецификатор длины в этом случае действительно является ограничением, и его использование на самом деле не рекомендуется. (см)

Другие СУБД требуют от пользователя выбора, если ему требуется «неограниченное», внешнее хранилище, обычно с сопутствующими затратами на удобство и / или производительность.

Если есть преимущество в использовании VARCHAR(<n>) над VARCHAR(MAX) или TEXT, из этого следует, что вы должны выбрать значение для <n> при разработке таблиц. Предполагая, что есть некоторая максимальная ширина строки таблицы или записи индекса, должны применяться следующие ограничения:

1. <n> должно быть меньше или равно <max width>
2. если <n> = <max width>, таблица / индекс может иметь только 1 столбец
3. в общем случае таблица / индекс может иметь только столбцы <x>, где (в среднем) <n> = <max width> / <x>

Следовательно, не означает, что значение <n> действует только как ограничение, и выбор <n> должен быть частью проекта. (Даже если в вашей СУБД нет жесткого ограничения, вполне возможно, что для сохранения ширины в пределах определенного предела могут быть причины производительности.)

Вы можете использовать вышеприведенные правила, чтобы назначить максимальное значение <n> на основе ожидаемой архитектуры вашей таблицы (с учетом влияния будущих изменений). Однако имеет смысл определить минимальное значение <n> на основе ожидаемых данных в каждом столбце. Скорее всего, вы будете расширяться до ближайшего «круглого числа» - например, вы всегда будете использовать VARCHAR(10), VARCHAR(50), VARCHAR(200) или VARCHAR(1000), в зависимости от того, что лучше всего подходит.

Answer 4

Так почему же люди стараются сделать свои столбцы как можно меньше? Я не верю, чтобы сделать их как можно меньше, но подбираю их соответствующим образом. Некоторые причины для того, чтобы сделать (n) varchars меньше, чем больше:

1) При увеличении поля все клиенты, использующие базу данных, должны иметь возможность обрабатывать полный размер. Например, возьмем систему, которая содержит адрес Соединенных Штатов с 255 символами в каждом поле: (я полагаю, что аналогично TDWTF, на который вы ссылаетесь).

• Имя
• Фамилия
• Адресная строка 1
• Адресная строка 2
• Город * * 1016
• Штат
• Почтовый индекс

Теперь ваши экраны ввода данных должны позволять и показывать 255 символов в каждом поле. Не сложно, но вряд ли будет хорошо выглядеть с большими полями. Для печати счетов-фактур вам потребуется логика разрыва строк для обработки больших полей. В зависимости от инструмента, не так сложно.

Но я бы не хотел проблему форматирования адреса для конверта, который мог бы иметь 255 символов для каждого из этих полей или только для одного из этих полей. Собираетесь ли вы урезать, если поле слишком длинное, чтобы уместиться? Великий, у кого-то есть Адресная Строка 1 из "Номер дома, Номер Дома ... бла-бла-бла ... Квартира № 111". И вы отбросите важный номер квартиры. Собираетесь ли вы завернуть? Сколько? Что делать, если вы просто не можете поместить его в маленькую коробочку с пространством на конверте? Возбудить исключение и попросить кого-нибудь написать это?

2) Хотя 10 символов данных, хранящихся в varchar (50) по сравнению с varchar (255), не влияют на размер или скорость, разрешение 255 символов позволяет занять больше места. И если все поля настолько велики, вы можете установить ограничения по размеру в SQL Server 2000. (Я не читал в 2005 и 2008 годах, чтобы посмотреть, могут ли они обрабатывать строки размером более одной страницы.) И с Oracle, большие размеры позволяют строки цепочка произойдет, если кто-то использует все доступные символы.

3) Индексы имеют более строгие ограничения по размеру, чем конечные страницы. Вы можете исключить индексы, особенно составные индексы, если вы создаете слишком большие ваши varchars.

---

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

Answer 5

Простой ответ на этот вопрос, на мой взгляд, заключается в том, что вы не можете использовать этот столбец в качестве ключа индекса, если вам требуется какая-либо индексация, вы в основном вынуждены использовать полный текст ... это касается использования varchar (max) колонка. В любом случае столбцы «правильного размера» имеют большой смысл всякий раз, когда вы хотите применить индексацию; Обновление столбцов переменной длины может быть дорогостоящим маневром, поскольку они не сделаны на месте и могут / будут вызывать некоторую фрагментацию.

Все, что касается MS SQ-Server.

Answer 6

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

Answer 7

Я отвечу на ваш вопрос вопросом: если между СУБД нет разницы между varchar (50) и varchar (255), почему СУБД позволяет вам проводить различие? Почему бы СУБД просто не сказать «используйте varchar для символов до ххх, а текст / clob / и т. Д. Для чего-либо сверх этого». Несомненно, возможно, Microsoft / Oracle / IBM могли бы сохранить определение длины по историческим причинам, но как насчет СУБД, такой как MySQL, которая имеет несколько бэкэндов хранения - почему каждая из них реализует определяемые длины столбцов символов?

Answer 8

Если вы допустите, чтобы длина данных превышала 255, и кто-то связывается с данными через MS Access, эти данные нельзя использовать для объединения таблиц (в качестве памятного поля). Если данные экспортируются в Excel, они будут ограничены 255 символами на поле. Совместимость с другими программами должна учитываться при создании наборов данных.
Контроль качества данных - все о контроле данных, поступающих в вашу среду. Что нужно для хранения более 255 символов? Бывают случаи, когда данные должны содержать более 255 символов, но их должно быть далеко и мало между ними, и их следует использовать в качестве вспомогательной дополнительной информации для поля, которое можно использовать для анализа