Есть ли причина использовать размеры VARCHAR, округленные до смещения 128/256/4096 байт?

В схемах базы данных я часто замечаю, что размеры VARCHAR округлены до смещений байтов 128/256 или 4096. Я делал это и раньше, и идея, вероятно, заключалась в эффективности.

Тем не менее, есть ли еще веская причина сделать это в наши дни? В настоящее время я часто использую «50», «100» или «200» в качестве размеров VARCHAR, поскольку они более естественны и, как правило, также показываются пользователю при проверках достоверности.

Единственное разумное объяснение, которое я могу придумать, было бы: если СУБД хранит значения столбца последовательно, а размеры не округляются до степени 2, то некоторые элементы, возможно, придется «разбить» на две страницы на жестком диске. диск (например, первые 10 байтов на странице n и следующие 40 байтов на странице n + 1), что в некоторых случаях может привести к двум чтениям с жесткого диска вместо одного.

Скорее всего, @Jan Hudec считает, что многие программисты считают «128» или «256» «хорошими круглыми числами», что делает их более естественным выбором, чем нечетные числа, такие как 137, 19 или 100.

В общем случае нет причин для такой длины столбца. Не будет никакого улучшения производительности столбца varchar (100) по сравнению со столбцом varchar (128).

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

Например, вот хороший пример ограничения системы базы данных для SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

Общая длина строки важнее, чем длина отдельных столбцов.

Я не помню, была ли это СУБД или компилятор, но я вспоминаю (давно), что учился использовать степени 2 для длины массива и столбца. Было оправдание, что это было «быстрее», потому что реализация могла использовать сдвиг битов. Верно ли больше, остается открытым вопросом. Кто-нибудь есть какие-либо идеи о том, является ли он все еще действительным?

Кстати, я переместил ширину столбцов в единое число b / c, странно говорить пользователям, что ограничение символа составляет 256 символов.

И некоторые очень старые базы данных ограничивали вас 256 столбцами ширины символов.

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

Это может иметь больше смысла, если вы работаете с большими (4 КБ или более) столбцами, так как они могут храниться отдельно, а их размер можно разместить так, чтобы они помещались в один блок хранения (независимо от того, какую базу данных использует для хранения на диске). ты что-то

Хотя я не знаком со всеми системами СУБД, самая маленькая «физическая» единица хранения в Oracle - это «блок», размер которого по умолчанию составляет 2 КБ. Практика определения размеров столбцов в степени двух является частью более широкой практики определения размеров строк, чтобы они правильно помещались в блоки хранения. Определение размера столбцов таким образом, чтобы для одной строки потребовался на один байт больше, чем для размера блока, потребовалось бы выделить два блока, и ваша строка также будет занимать два блока, что делает чтение, вставку и сканирование более трудоемким, чем если бы вы могли уместить каждую строку на один блок (и только один ряд в каждом блоке). Это, по крайней мере, историческая причина этого. В настоящее время большинство людей считают эту практику субоптимизацией.