Размеры столбцов базы данных для символьных данных

Question

Я только что натолкнулся на базу данных, в которой все символьные столбцы имеют размер, кратный 8 (например, Username = varchar (32), Forename = nvarchar (128) и т. Д.). производительность базы данных или это совершенно бессмысленно?

Спасибо.

N.B. Это в базе данных SQL 2000.

Answer 1

Поскольку они являются VAR-символами, фактическое используемое пространство зависит от содержимого. Я бы начал беспокоиться, если бы они были символами.

-Edoode

Answer 2

«Будет ли это иметь какое-либо отношение к производительности базы данных или это совершенно бессмысленно?»

Это мало влияет на производительность (не мало, но мало). Это может повлиять на распределение свободного пространства, так как при этой схеме «самый большой» размер строки может быть довольно большим. Несколько строк на странице могут замедлить поиск больших таблиц.

Разница, однако, обычно микроскопическая по сравнению с неправильной индексацией.

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

Теперь, когда диск настолько дешев, время DBA, потраченное на суету с размерами, стоит больше, чем диск.

Answer 3

Это, наверное, просто привычка какого-то старого школьного разработчика. Как уже говорилось - varchar - это столько, сколько нужно, поэтому 32 или 33 не имеют значения, когда длина строки равна, например, 22.

Answer 4

Я никогда не видел, чтобы это имело значение для хранения таблиц, объединений или основных операций.

Но я видел разницу в обработке строк.

В SQL Server 2005 единственный случай, когда размер varchar имеет существенные различия, - это когда все преобразуется в varchar (MAX) или в UDF. Там, кажется, есть некоторое различие - например, у меня есть система / процесс, который я портирую с несколькими ключевыми столбцами, которые должны быть объединены вместе в другое псевдо-ключевое поле (пока я не смогу реорганизовать эту мерзость) и запрос выполнялся значительно лучше, передавая результат как varchar (45) как можно быстрее в промежуточных CTE или вложенных запросах.

Я видел случаи, когда UDF, принимающий и возвращающий varchar (MAX), работает значительно хуже, чем, например, принимающий и возвращающий varchar (50). Например, функция обрезки или заполнения, которую кто-то (возможно, я!) Пытался сделать будущим доказательством. У varchar (MAX) есть свое место, но по моему опыту это может быть опасно для производительности.

Не думаю, что я описал разницу между varchar (50) и varchar (1000).

Answer 5

У вас были бы одинаковые опасения, если бы они были кратны 5 или 10, что и происходит в обычном случае?

Answer 6

Мне кажется, преждевременная оптимизация.

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