Почему использование короче VARCHAR (n) поля?
Часто рекомендуется выбрать размеры поля базы данных, чтобы быть максимально узким. Я задаюсь вопросом, до какой степени это относится к SQL Server 2005 VARCHAR столбцы: Хранение английских слов с 10 буквами в a VARCHAR(255) поле не поднимет больше устройства хранения данных, чем в a VARCHAR(10) поле.
Там другие причины состоят в том, чтобы ограничить размер полей VARCHAR, чтобы придерживаться максимально тесно размера данных? Я думаю
- Производительность: существует ли преимущество для использования меньшего n при выборе, фильтрации и сортировке на данных?
- Память, включая на стороне приложения (C++)?
- Стиль/проверка: Как важный Вы считаете ограничение colunm размером, чтобы вынудить бессмысленный импорт данных перестать работать (такие как фамилии с 200 символами)?
- Что-нибудь еще?
Фон: Я помогаю интеграторам данных с дизайном потоков данных в поддержанную базой данных систему. Они должны использовать API, который ограничивает их выбор типов данных. Для символьных данных, только VARCHAR(n) с n <= 255 доступно; CHAR, NCHAR, NVARCHAR и TEXT не. Мы пытаемся установить некоторые "хорошие методы" правила, и вопрос подошел, если существует реальный вред к использованию VARCHAR(255) даже для данных, где реальные максимальные размеры никогда не будут превышать 30 байтов или около этого.
Типичные объемы данных для одной таблицы являются 1-10 записями Mio максимум с 150 атрибутами. Производительность запросов (SELECT, с часто обширным WHERE пункты), и выполнение извлечения прикладной стороны являются главными.
5 ответов
Целостность данных - безусловно, самая важная причина. Если вы создадите столбец под названием
Фамилия, содержащий 255 символов, вы, скорее всего, получите больше, чем фамилии. Вы получите имя, фамилию, отчество. Вы получите своего любимого питомца. Вы получите «Алису в бухгалтерии с треугольными волосами». Короче говоря, вы упростите пользователям использование столбца в качестве столбца для заметок / фамилии. Вы хотите, чтобы ограничение препятствовало пользователям, которые пытаются указать в этом столбце что-то, кроме фамилии. Если у вас есть столбец, который требует определенной длины (например, налоговый идентификатор США состоит из девяти символов), но столбец имеет видvarchar (255), другие разработчики будут интересоваться, что происходит и ] вы, вероятно, также получите дерьмовые данные.Индексирование и ограничения строк. В SQL Server у вас есть ограничение в 8060 байт IIRC. Множество толстых столбцов без varchar (max) с большим количеством данных могут быстро превысить этот предел.Кроме того, у индексов есть верхний предел шириной 900 байт IIRC. Итак, если вы хотите проиндексировать столбец с фамилией и некоторые другие столбцы, содержащие много данных, вы можете превысить этот предел.
Отчетность и внешние системы. Как дизайнер отчетов вы должны предположить, что если столбец объявлен с максимальной длиной 255, он может содержать 255 символов. Если пользователь может это сделать, они это сделают. Таким образом, можно сказать: «Вероятно, в нем не будет более 30 символов». это даже отдаленно не то же самое, что «Он не может содержать более 30 символов». Никогда не полагайтесь на первое. Как дизайнер отчетов, вы должны обойти возможности того, что пользователи будут вводить набор данных в столбец. Это означает либо усечение значений (и если это так, то зачем нужно дополнительное пространство?), Либо использование CanGrow для создания прекрасного беспорядка в отчете. В любом случае, вы усложняете другим разработчикам понимание назначения столбца, если размер столбца так далеко не совпадает с фактическими сохраняемыми данными.
Я думаю, что самая большая проблема - это проверка данных. Если вы разрешите 255 символов для фамилии, вы получите фамилию, длина которой превышает 200 символов в вашей базе данных.
Другая причина заключается в том, что если вы позволяете базе данных содержать 255 символов, вам теперь придется учитывать эту возможность в каждой системе, которая касается вашей базы данных. Например, если вы экспортировали в файл столбца фиксированной ширины, все ваши столбцы должны быть 255 символов в ширину, что может быть довольно раздражающим или даже проблематичным. Это всего лишь один пример, когда это может вызвать проблему.
1) Читабельность и поддержка
Разработчик базы данных может посмотреть на поле StateCode с длиной varchar(2) и получить хорошее представление о том, какие данные хранит это поле, даже не глядя на его содержимое.
2) Отчетность
Когда ваши данные не имеют ограничений по длине, вы ожидаете, что разработчик обеспечит, чтобы все данные столбцов были одинаковой длины. Если разработчик не смог обеспечить согласованность данных столбцов, то при составлении отчетов эти данные будут выглядеть непоследовательно и смешно.
3) Хранение данных SQL Server
SQL Server хранит данные на 8k "страницах", и с точки зрения производительности идеально быть как можно более эффективным и хранить как можно больше данных на странице.
Если ваша база данных рассчитана на хранение всех строковых колонок в виде varchar(255), "плохие" данные могут попасть в одно из этих полей (например, название штата может попасть в поле StateCode, которое должно быть длиной 2 символа) и вызвать ненужные и неэффективные разбиения страниц и индексов.
Одна веская причина - проверка.
(например) В Голландии номер социального страхования всегда состоит из 9 символов, если вы не разрешите больше, этого никогда не произойдет.
Если вы разрешите больше и по какой-то неизвестной причине есть 10 символов, вам нужно будет поставить проверки (которые в противном случае вы бы не сделали), чтобы проверить, является ли он длинным.
Другое дело, что одна строка данных ограничена 8060 байтами, и SQL Server использует максимальную длину полей varchar для определения этого.
Ссылка: http://msdn.microsoft.com/en-us/library/ms143432.aspx