Какой размер выбрать для (n) varchar столбец?
На самом деле я полагаю, что это было бы самым быстрым:
SELECT ProductID, ProductName
FROM Northwind..Products p
outer join Northwind..[Order Details] od on p.ProductId = od.ProductId)
WHERE od.ProductId is null
6 ответов
Я могу говорить только от лица Oracle. VARCHAR2 (50) и VARCHAR2 (255) занимают одинаковое количество места и работают одинаково, если вы вводите значение SMITH.
Однако причина, по которой обычно не рекомендуется объявлять все текстовые столбцы как VARCHAR2 (4000), состоит в том, что длина столбца, по сути, является еще одним ограничением. А ограничения - это реализация бизнес-правил базой данных, поэтому они определенно должны быть определены на стороне базы данных.
В качестве примера. Вы определяете ограничение CHECK для столбца, чтобы значения, которые он мог принимать, были только «Y» и «N». Это избавляет ваше приложение от необходимости иметь дело с «y» и «n» или даже с «1» и «0». Ограничение check гарантирует, что ваши данные соответствуют ожидаемым стандартам. Затем код вашего приложения может сделать допустимые предположения о природе данных, с которыми он должен иметь дело.
Определение длины столбца находится в той же лодке. Вы объявляете что-то как VARCHAR2 (10), потому что не хотите, чтобы он принимал запись 'ABC123ZYX456' (по какой-либо причине!)
В Австралии я определяю столбцы STATE как varchar2 (3), потому что я не Не хочу, чтобы люди набирали «Новый Южный Уэльс» или «Южная Австралия». Определение столбца в значительной степени заставляет их вводить как «NSW» и «SA». В этом смысле VARCHAR2 (3) является почти таким же проверочным ограничением, как и фактическое определение ограничения CHECK IN ('NSW', 'SA', 'VIC' и т. Д.).
Короче говоря, правильная длина столбца - это способ кодирования бизнес-правил. Это еще одна форма принуждения. Они обладают всеми преимуществами ограничений (и страдают многими из тех же недостатков). И они обеспечивают, в некоторой степени, степень «чистоты данных», с которой также помогают «правильные» ограничения.
Я также не верю аргументу, что лучше всего вставлять такие вещи в клиентское приложение, потому что там проще поменять. У вас 20 000 человек используют приложение, это 20 000 обновлений. У вас одна база данных, это одно обновление. Аргумент «легче изменить клиентское приложение», если он истинен, потенциально может означать, что база данных будет рассматриваться как гигантский битовый блок со всей умной логикой, обрабатываемой в клиентском коде. Это серьезное обсуждение, но поскольку все СУБД позволяют определять ограничения и т. Д. В самой базе данных, довольно ясно, что там '
Я слышал, что оптимизатор запросов действительно учитывает длину varchar, хотя я не могу найти ссылку.
Определение длины varchar помогает передать намерение. Чем больше ограничений определено, тем надежнее данные.
Так почему же люди стараются делать свои столбцы как можно меньше? Я не верю в то, чтобы делать их как можно меньше, но подбирая их размер соответствующим образом. Некоторые причины для уменьшения (n) varchars, а не большего:
1) С большим полем все клиенты, использующие базу данных, должны иметь возможность обрабатывать полный размер. Например, возьмем систему, которая содержит адрес США с 255 символами в каждом поле: (Я полагаю, аналогично указанному вами TDWTF.)
- Имя
- Фамилия
- Строка адреса 1
- Адресная строка 2
- Город
- Штат
- Почтовый индекс
Теперь ваши экраны ввода данных должны будут разрешать и отображать 255 символов в каждом поле. Несложно, но вряд ли будет хорошо смотреться с большими полями. При печати счетов-фактур вам понадобится логика разрыва строки для обработки больших полей. В зависимости от инструмента, не так уж и сложно.
Но я бы не хотел проблему форматирования адреса для конверта, который может содержать 255 символов для каждого из этих полей или только для любого из этих полей. Собираетесь ли вы обрезать поле, если оно слишком длинное? У кого-то есть адресная строка 1 "Номер дома Номер улицы ... бла-бла-бла ... Квартира номер 111." И вы отрежете важный номер квартиры. Собираешься заворачивать? Сколько? Что, если вы просто не можете вместить его в маленькую коробку на конверте? Вызвать исключение и попросить кого-нибудь написать его?
2) Хотя 10 символов данных, содержащихся в varchar (50) по сравнению с varchar (255), не влияют на размер или скорость, разрешение 255 символов позволяет занять больше места. И если все поля будут такими большими, вы можете достичь ограничений по размеру в SQL Server 2000 (я не читал 2005 и 2008, чтобы узнать, могут ли они обрабатывать строки размером больше одной страницы.) А с Oracle большие размеры позволяют создавать цепочки строк, если кто-то действительно использует все доступные символы.
3) У индексов более строгие ограничения по размеру, чем у конечных страниц. Вы можете исключить индексы, особенно составные индексы, если вы создаете слишком большие символы varchars.
С другой стороны, у меня длинная строка 1 для моего адреса, и я был разочарован веб-сайтами, которые не позволяют полностью набрать.
Я отвечу на ваш вопрос вопросом: если в СУБД нет разницы между varchar (50) и varchar (255), почему СУБД позволяет вам делать различие ? Почему бы СУБД просто не сказать «используйте varchar для символов до xxx, а text / clob / и т. Д. - для всего, что сверх этого». Конечно, возможно, Microsoft / Oracle / IBM могут сохранить определение длины по историческим причинам, но как насчет СУБД, таких как MySQL, которые имеют несколько бэкэндов для хранения - почему каждая из них реализует определяемую длину столбцов символов?
Простой ответ на мой взгляд, это тот факт, что вы не можете использовать этот столбец в качестве ключа индекса, если вам требуется какое-либо индексирование, вы в основном вынуждены использовать полнотекстовый ... это касается использования столбца varchar (max). В любом случае «правильный размер» столбцов имеет смысл всякий раз, когда вы [можете] захотите применить какое-либо индексирование; обновление столбцов переменной длины может быть дорогостоящим маневром, поскольку оно не выполняется на месте и может / вызовет некоторую фрагментацию.
Все в отношении MS SQ-Server.
Одно важное различие заключается между указанием произвольно большого предела [например, VARCHAR (2000) ] и использованием типа данных, который не требует ограничения [например, VARCHAR (MAX) или TEXT ].
PostgreSQL основывает все свои VARCHAR фиксированной длины на своем неограниченном типе TEXT и динамически определяет на значение , как сохранить значение, в том числе вне страницы. Спецификатор длины в этом случае действительно является ограничением, и его использование не рекомендуется. (ссылка)
Другие СУБД требуют от пользователя выбора, требуется ли им «неограниченное» внестраничное хранилище, обычно с соответствующими затратами на удобство и / или производительность.
Если есть преимущество в использовании VARCHAR ( вместо VARCHAR (MAX) или TEXT , из этого следует, что вы должны выбрать значение для при создании таблиц. Предполагая, что существует некоторая максимальная ширина строки таблицы или записи индекса, должны применяться следующие ограничения:
- if
], таблица / индекс может иметь только 1 столбец= - в целом, таблица / индекс может иметь только
= /
Следовательно, не тот случай, когда значение действует только как ограничение, и выбор должен быть частью дизайна. (Даже если в вашей СУБД нет жесткого ограничения, вполне могут быть причины производительности, чтобы удерживать ширину в пределах определенного предела.)
Вы можете использовать приведенные выше правила, чтобы назначить максимальное значение на основе ожидаемая архитектура вашей таблицы (с учетом влияния будущих изменений). Однако имеет смысл определить минимальное значение на основе ожидаемых данных в каждом столбце. Скорее всего, вы расширитесь до ближайшего «круглого числа» - например, вы всегда будете использовать либо VARCHAR (10) , VARCHAR (50) , VARCHAR (200) или VARCHAR (1000) , в зависимости от того, что лучше всего подходит.
Вы можете использовать приведенные выше правила, чтобы назначить максимальное значение на основе ожидаемой архитектуры вашей таблицы (с учетом влияния будущих изменений) . Однако имеет смысл определить минимальное значение на основе ожидаемых данных в каждом столбце. Скорее всего, вы расширитесь до ближайшего «круглого числа» - например, вы всегда будете использовать либо VARCHAR (10) , VARCHAR (50) , VARCHAR (200) или VARCHAR (1000) , в зависимости от того, что лучше всего подходит.
Вы можете использовать приведенные выше правила, чтобы назначить максимальное значение на основе ожидаемой архитектуры вашей таблицы (с учетом влияния будущих изменений) . Однако имеет смысл определить минимальное значение на основе ожидаемых данных в каждом столбце. Скорее всего, вы расширитесь до ближайшего «круглого числа» - например, вы всегда будете использовать либо VARCHAR (10) , VARCHAR (50) , VARCHAR (200) или VARCHAR (1000) , в зависимости от того, что лучше всего подходит.
VARCHAR (10) , VARCHAR (50) , VARCHAR (200) или VARCHAR (1000) , в зависимости от того, что лучше всего подходит. на основе ожидаемых данных в каждом столбце. Скорее всего, вы расширитесь до ближайшего «круглого числа» - например, вы всегда будете использовать либо VARCHAR (10) , VARCHAR (50) , VARCHAR (200) или VARCHAR (1000) , в зависимости от того, что лучше всего подходит.