Czy istnieje powód, aby używać rozmiarów VARCHAR zaokrąglonych do przesunięcia bajtu 128/256/4096?

W schematach baz danych często zauważam, że rozmiary VARCHAR są zaokrąglane do przesunięć bajtów 128/256 lub 4096. Zrobiłem to już wcześniej, a pomysł, który za tym stoi, był prawdopodobnie skuteczny.

Czy jednak istnieje obecnie uzasadniony powód, aby to zrobić? Obecnie często używam „50”, „100” lub „200” jako rozmiarów VARCHAR, ponieważ są one bardziej naturalne i zwykle są również wyświetlane użytkownikom podczas sprawdzania poprawności.

Jedynym racjonalnym wytłumaczeniem, które mogę wymyślić, byłoby: Jeśli DBMS przechowuje wartości kolumny sekwencyjnie, a rozmiary nie są zaokrąglane do potęgi 2, wówczas niektóre elementy mogą wymagać podziału na dwie strony na twardym dysk (np. pierwsze 10 bajtów na stronie n i kolejne 40 bajtów na stronie n + 1), co może w niektórych przypadkach prowadzić do dwóch odczytów z dysku twardego zamiast jednego.

Bardziej prawdopodobne jest stwierdzenie @Jana Hudeca, że ​​wielu programistów uważa „128” lub „256” za „ładne okrągłe liczby”, co czyni je bardziej naturalnymi wyborami niż liczby nieparzyste, takie jak 137, 19 lub 100.

Zasadniczo nie ma powodu dla tych długości kolumn. Nie będzie poprawy wydajności kolumny varchar (100) w porównaniu z kolumną varchar (128).

Chciałbym jednak dokładnie sprawdzić system bazy danych, z którego korzystasz, w celu dalszego wyjaśnienia ograniczeń i innych ograniczeń specyficznych dla dostawców.

Na przykład oto dobry przykład ograniczenia systemu bazy danych dla programu SQL Server:

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

Całkowita długość wiersza jest ważniejsza niż poszczególne długości kolumn.

Nie pamiętam, czy był to DBMS, czy kompilator, ale pamiętam (dawno temu) uczenie się używania mocy 2 dla długości tablic i kolumn. Istnieje uzasadnienie, że było „szybsze”, ponieważ implementacja może wymagać przesunięcia bitów. To, czy jest już prawdą, jest pytaniem otwartym. Czy ktoś ma pomysł, czy nadal jest ważny?

BTW Przesunąłem szerokości kolumn do jednolitej liczby b / c, dziwne jest mówienie użytkownikom, że limit znaków wynosi 256 znaków.

Niektóre bardzo stare bazy danych ograniczały cię do 256 kolumn o szerokości znaków.

Prawdopodobnie nie ma to tak naprawdę znaczenia, ponieważ naprawdę zobaczyłbyś pewną wydajność pamięci, gdyby rozmiar całego wiersza był potęgą 2. Możliwe, że trzymanie się potęg 2 może zwiększyć prawdopodobieństwo, że rozmiar wiersza sprawdziłby się do potęgi dwóch (ponieważ większość rodzimych typów danych zwykle ma potęgę wielkości 2 [w zależności od bazy danych]), ale nie uczyniłbym tego trudną i szybką regułą.

Może to mieć większy sens, jeśli pracujesz z dużymi (4K lub większymi) kolumnami, ponieważ mogłyby one być przechowywane osobno, a ich zmiana tak, aby mieściły się w jednym bloku pamięci (cokolwiek baza danych używa do przechowywania na dysku) zyskałaby ty coś.

Chociaż nie znam wszystkich systemów DBMS, najmniejszą „fizyczną” jednostką pamięci w Oracle jest „blok”, który domyślnie ma rozmiar 2 KB. Praktyka określania wielkości kolumn w potęgach dwóch jest częścią większej praktyki polegającej na dopasowywaniu rzędów do bloków pamięci. Zmiana wielkości kolumn tak, aby jeden wiersz wymagałby o jeden bajt więcej niż rozmiar bloku, wymagałaby przydzielenia dwóch bloków, a także wiersz obejmujący dwa bloki, co sprawia, że ​​czytanie, wstawianie i skanowanie zajmuje więcej czasu niż w przypadku dopasowania każdego wiersza do jednego bloku (i tylko jeden wiersz w każdym bloku). To przynajmniej historyczny powód. W dzisiejszych czasach większość ludzi uważa tę praktykę za suboptymalizację.