Чи є якась причина використовувати розміри 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 для масивів та довжин стовпців. Було обгрунтування, що це "швидше", оскільки впровадження може використовувати зміщення бітів. Чи справді це справді вже є питанням відкритим. У когось є ідея щодо того, чи вона все ще діє?

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

І деякі дуже старі бази даних обмежили вас 256 колонками ширини.

Це, мабуть, насправді не має значення, оскільки ви дійсно бачите лише деяку ефективність зберігання, якщо розмір усього рядка виявився потужністю 2. Можливо, що дотримання потужностей 2 може зробити більш імовірним розмір вашого рядка працював би з потужністю до двох (оскільки більшість власних типів даних мають тенденцію до 2-х розмірів [залежно від бази даних]), але я не став би це жорстким правилом.

Це може мати більше сенсу, якщо ви працювали з великими (4K або більшими) стовпцями, оскільки вони, можливо, можуть зберігатися окремо, і розміром їх так, щоб вони вміщувалися в один блок зберігання (що б ваша база даних не використовувала для зберігання на диску). ти щось.

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