завышение размера поля в дизайне базы данных

У меня есть некоторые поля для моих таблиц, которые являются строками, и в настоящее время большая часть размера полей имеет довольно высокие ограничения символов. Например, 100 символов для названия улицы. Есть ли штраф за использование большого размера поля? Если я изменю ограничение на 30 символов, например, для этого поля, будет ли увеличение производительности или эффективность с размером? Было бы около 50 полей, которые могли бы быть кандидатами на усадку.

Спасибо за ваши предложения.

Если вы говорите, varcharа nvarcharзатем нет, штраф за увеличение длины поля не взимается.

Однако следует иметь в виду некоторые предостережения:

• Для полей переменной длины (для каждого поля) накладываются 2 байта на строку . Если у вас очень короткое поле, возможно, имеет смысл использовать CHAR. Varchar(2)например, фактически использует от 2 до 4 байтов на строку, в то время как CHAR(2)всегда использует 2.
• Очень длинные поля не могут быть проиндексированы. Максимальная длина для всех полей в наборе ключей индекса составляет 900 байтов.
• Если вы допустите больше данных, чем ожидаете, вы в конечном итоге получите неожиданные результаты. Если вы допустите 100 символов для названия улицы, в какой-то момент другие данные могут попасть в это поле без вашего ведома (например, полный адрес). Если бы вы имели соответствующий размер, вы, скорее всего, получили бы ошибку при вставке.
• Разрешение очень широких строк может привести к разбиению страницы и фрагментации. Если у вас есть строка длиннее 8 КБ, ее нужно будет разбить на несколько страниц данных. Многие из них могут действительно повредить производительности. Сужение в целом более эффективно.

Если вы имеете в виду: «Есть ли штраф за объявление размера поля больше, чем любые значения, которые в нем хранятся?», Тогда, пока он объявлен как varchar, ответ будет отрицательным. Каждый известный мне механизм БД SQL хранит только количество символов, фактически заданных в данных (плюс значение длины). Таким образом, если вы определяете поле как varchar (100), но сохраняете в нем только 10 символов, тогда оно займет всего 10 символов на диске (плюс 2 байта или около того для длины). Когда я сомневаюсь, я обычно делаю свои поля вархаров смехотворно большими.

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

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

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

Любой, утверждающий, что штраф за объявление размера поля больше, чем то, что фактически будет храниться в таблице, является неверным. Фактический размер данных (плюс 2-байтовые издержки) - это то, что на самом деле сохраняется, но это определение столбца, которое используется для определения оценки, насколько идет план выполнения. Таким образом, хотя объявление varchar (1000) для хранения значения из 10 символов потребляет только 12 символов дискового пространства, оценки плана выполнения будут намного менее эффективными и отрицательно искажают результаты, как для объема памяти, выделяемого для операции, так и для может ли операция выполняться только в памяти или для нее также потребуется место на диске tempdb. Вы можете сделать свой столбец varchar (1000), но движок не знает, что все ваши сохраненные значения действительно меньше, чем varchar (10),

Проверка длины поля - это то, что вы получаете «бесплатно», то есть вам не нужно использовать CHECKограничение, чтобы сделать то же самое. И вам не нужны слишком большие значения данных, когда, например, вы должны загрузить свои данные в другую базу данных, в которой этот же элемент данных ограничен 35 символами в соответствии с международным стандартным адресом.