Dlaczego historycznie ludzie używają 255 zamiast 256 dla wielkości pola bazy danych?

Często widzisz pola bazy danych o wielkości 255 znaków. Jaki jest tradycyjny / historyczny powód, dla którego? Zakładam, że ma to związek z limitami stronicowania / pamięci i wydajnością, ale rozróżnienie między 255 a 256 zawsze mnie myliło.

varchar(255)

Biorąc pod uwagę, że jest to pojemność lub wielkość, a nie indeksator , dlaczego 255 jest preferowane zamiast 256? Czy bajt jest zarezerwowany do jakiegoś celu (terminator, null lub coś takiego)?

Prawdopodobnie varchar (0) jest nonsensem (ma zerową pojemność)? W którym przypadku 2 ^ 8 miejsca powinno z pewnością wynosić 256?

Czy istnieją inne wielkości, które zapewniają korzyści w zakresie wydajności? Na przykład czy varchar (512) jest mniej wydajny niż varchar (511) czy varchar (510)?

Czy ta wartość jest taka sama dla wszystkich baz danych relacji, starych i nowych?

zrzeczenie się odpowiedzialności - nie jestem programistą DBA, używam rozmiarów i typów pól, które pasują do mojej logiki biznesowej tam, gdzie jest to znane, ale chciałbym poznać historyczny powód tej preferencji, nawet jeśli nie jest to już istotne (ale nawet więcej, jeśli nadal jest to istotne).

Edytować:

Dzięki za odpowiedzi, wydaje się, że istnieje pewna koncensja, że ​​bajt jest używany do przechowywania wielkości, ale to nie rozstrzyga ostatecznie sprawy w mojej głowie.

Jeśli metadane (długość łańcucha) są przechowywane w tej samej ciągłej pamięci / dysku, ma to sens. 1 bajt metadanych i 255 bajtów danych łańcuchowych bardzo dobrze do siebie pasowałoby i mieściłby się w 256 ciągłych bajtach pamięci, co prawdopodobnie jest czyste i uporządkowane.

Ale ... Jeśli metadane (długość ciągu) są przechowywane oddzielnie od rzeczywistych danych ciągu (być może w głównej tabeli), to aby ograniczyć długość danych ciągu przez jeden bajt, tylko dlatego, że łatwiej jest przechowywać tylko 1 bajtową liczbę całkowitą metadanych wydaje się nieco dziwny.

W obu przypadkach wydaje się to subtelnością, która prawdopodobnie zależy od implementacji DB. Praktyka używania 255 wydaje się dość rozpowszechniona, więc ktoś gdzieś musiał na początku argumentować za tym, czy ktoś może sobie przypomnieć, co to była / jest ta sprawa? Programiści nie przyjmą żadnej nowej praktyki bez powodu, a to kiedyś musiało być nowe.

Przy maksymalnej długości 255 znaków DBMS może wybrać pojedynczy bajt do wskazania długości danych w polu. Gdyby limit wynosił 256 lub więcej, potrzebne byłyby dwa bajty.

Wartość długości zero jest z pewnością poprawna dla varchardanych (chyba że jest ograniczona inaczej). Większość systemów traktuje taki pusty ciąg jako inny niż NULL, ale niektóre systemy (zwłaszcza Oracle) traktują pusty ciąg identycznie jak NULL. W systemach, w których pusty ciąg nie ma wartości NULL, potrzebny byłby dodatkowy bit gdzieś w wierszu, aby wskazać, czy wartość należy uznać za NULL, czy nie.

Jak zauważasz, jest to optymalizacja historyczna i prawdopodobnie nie jest odpowiednia dla większości dzisiejszych systemów.

255 był limitem varchar w mySQL4 i wcześniejszych.

Również 255 znaków + Null terminator = 256

Lub 1-bajtowy deskryptor długości daje możliwy zakres 0-255 znaków

255 to największa wartość liczbowa, którą można zapisać w jednobajtowej liczbie całkowitej bez znaku (przy założeniu 8-bitowych bajtów) - stąd aplikacje przechowujące długość łańcucha do określonego celu wolą 255 od 256, ponieważ oznacza to, że muszą tylko przydziel 1 bajt dla zmiennej „size”.

Z podręcznika MySQL:

Typ danych:
VARCHAR (M), VARBINARY (M)

Wymagana pamięć:
L + 1 bajtów, jeśli wartości kolumn wymagają 0–255 bajtów, L + 2 bajty, jeśli wartości mogą wymagać więcej niż 255 bajtów

Zrozum i dokonaj wyboru.

255 to maksymalna wartość 8-bitowej liczby całkowitej: 11111111 = 255.

Maksymalna długość 255 pozwala silnikowi bazy danych używać tylko 1 bajtu do przechowywania długości każdego pola. Masz rację, że 1 bajt miejsca pozwala na przechowanie 2 ^ 8 = 256 różnych wartości długości łańcucha.

Ale jeśli zezwolisz, aby pole przechowywało ciągi tekstowe o zerowej długości, musisz mieć możliwość przechowywania zera długości. Możesz więc zezwolić na 256 różnych wartości długości, zaczynając od zera: 0-255.

Często varchary są implementowane jako ciągi pascal: utrzymujące rzeczywistą długość w bajcie # 0. Długość została więc powiązana z 255. (Wartość bajtu waha się od 0 do 255.)

<<

Pamiętając o podstawach przechowywania bitów / bajtów, wymaga jednego bajtu do przechowywania liczb całkowitych poniżej 256 i dwóch bajtów dla dowolnej liczby całkowitej od 256 do 65536. Dlatego wymaga tej samej przestrzeni (dwa bajty) do przechowywania 511 lub 512 lub w tym przypadku 65535 .... Jest zatem jasne, że ten argument wymieniony w powyższej dyskusji jest nie dotyczy dla varchar (512) lub varchar (511).

8 bitów bez znaku = 256 bajtów

255 znaków + bajt 0 dla długości

Kiedyś wszystkie ciągi wymagały terminatora NUL lub „backslash-zero”. Zaktualizowane bazy danych tego nie mają. Było to „255 znaków tekstu” z dodanym automatycznie „\ 0” na końcu, aby system wiedział, gdzie kończy się łańcuch. Gdybyś powiedział VARCHAR (256), skończyłoby to na 257 i wtedy byłbyś w następnym rejestrze dla jednej postaci. Rozrzutny. Dlatego wszystko było VARCHAR (255) i VARCHAR (31). Wydaje się, że 255 z przyzwyczajenia utknęło wokół, ale 31 to 32, a 511 512. Ta część jest dziwna. Trudno zmusić mnie do napisania VARCHAR (256).

Myślę, że to może odpowiedzieć na twoje pytanie. Wygląda na to, że był to maksymalny limit varchar we wcześniejszych systemach. Zdjąłem to z kolejnego pytania o przepełnienie stosu.

Oczywiście nie wiadomo, jaki jest najdłuższy adres pocztowy, dlatego wiele osób wybiera długi VARCHAR, który z pewnością jest dłuższy niż jakikolwiek adres. A 255 jest zwyczajowo, ponieważ mogła być maksymalna długość VARCHAR w niektórych bazach danych na początku czasu (jak również PostgreSQL do niedawna).

Czy istnieją wady używania ogólnego varchar (255) dla wszystkich pól tekstowych?

Dane są zapisywane w pamięci w systemie binarnym, a 0 i 1 to cyfry binarne. Największa liczba binarna, która może zmieścić się w 1 bajcie (8 bitów) to 11111111, który konwertuje na 255 po przecinku.