Зачем использовать более короткие поля VARCHAR (n)?

часто рекомендуется выбирать размеры полей базы данных, чтобы быть как можно более узкими. Мне интересно, в какой степени это относится к SQL Server 2005 с VARCHAR столбцы: хранение 10-буквенных английских слов в VARCHAR(255) поле не займет больше места, чем в

8
sql sql-server types

5 ответов

  1. целостность данных-безусловно, самая важная причина. Если вы создадите столбец с именем Surname это 255 символов, вы, скорее всего, получите больше, чем фамилии. Ты получишь имя, фамилию, отчество. Вы получите своего любимого питомца. Вы получите "Алиса в бухгалтерии с треугольными волосами". Короче говоря, вы облегчите пользователям использование столбца в качестве столбца заметок/фамилий. Вы хочу крышка для того чтобы imped потребители которые пробуют положить что-то кроме фамилии в колонке. Если у вас есть столбец, который вызывает определенную длину (например, налоговый идентификатор США-девять символов), но столбец varchar(255), другие разработчики будут задаваться вопросом, что происходит и вы, вероятно, получите данные дерьмо, а также.

  2. индексирование и ограничения строк. В SQL Server у вас есть предел 8060 байт IIRC. Множество столбцов fat non-varchar (max) с большим количеством данных может быстро превысить этот предел. Кроме того, индексы имеют 900 байт cap в ширину IIRC. Таким образом, если вы хотите индексировать столбец фамилии и некоторые другие, содержащие много данных, вы можете превысить этот предел.

  3. отчетность и внешние системы. В качестве конструктора отчетов необходимо предположить, что если столбец объявлен с максимальной длиной 255, он может содержать 255 символов. Если пользователь может это сделать, он это сделает. Таким образом, сказать: "он, вероятно, не будет иметь более 30 символов."даже отдаленно не то же самое, что "он не может иметь больше, чем 30 символов.- Никогда не полагайся на первое. Как дизайнер отчетов, вы должны обойти возможности, которые пользователи будут вводить кучу данных в столбец. Что означает усечение значений (и если это так, почему есть дополнительные помещения?) или использование CanGrow, чтобы сделать прекрасный беспорядок отчета. В любом случае, вы усложняете другим разработчикам понимание цели столбца, если размер столбца настолько не соответствует фактическим данным на хранении.

13

Я думаю, что самая большая проблема-это проверка данных. Если вы разрешите 255 символов для фамилии, вы получите фамилию, которая составляет 200+ символов в вашей базе данных.

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

3

одна хорошая причина проверки.

(например) в Голландии номер социального страхования всегда составляет 9 символов, когда вы не позволите больше, это никогда не произойдет.

Если вы позволите больше и по какой-то неизвестной причине есть 10 символов, вам нужно будет поставить чеки (которые вы в противном случае не стали бы), чтобы проверить, если это 9 долго.

0

1) Читаемость И Поддержка

разработчик базы данных может посмотреть на поле под названием StateCode с длиной varchar (2) и получить хорошее представление о том, какие данные содержит это поле, даже не глядя на содержимое.

2) отчетность

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

3) хранилище данных SQL Server

SQL Server хранит данные на 8k "страницах", и с точки зрения производительности идеально быть максимально эффективным и хранить как можно больше данных на странице.

Если ваша база данных предназначена для хранения каждого столбца строки как varchar (255), "плохие" данные могут проскользнуть в одно из этих полей (например, имя состояния может проскользнуть в код состояния поле длиной 2 символа) и вызывает ненужные и неэффективные разбиения страниц и индексов.

0

другое дело, что одна строка данных ограничена 8060 байтами, и SQL Server использует максимальную длину полей varchar для определения этого.

ссылка:http://msdn.microsoft.com/en-us/library/ms143432.aspx

0