Czy jest dobry powód, dla którego widzę, że VARCHAR (255) jest używany tak często (w przeciwieństwie do innej długości)?

158

W wielu kursach, książkach i ofertach pracy widziałem pola tekstowe zdefiniowane jako VARCHAR (255) jako rodzaj domyślnego dla „krótkiego” tekstu. Czy jest jakiś dobry powód, dla którego długość 255 jest wybierana tak często, poza tym, że jest ładną okrągłą liczbą ? Czy jest to wstrzymanie od jakiegoś czasu w przeszłości, kiedy istniał dobry powód (niezależnie od tego, czy ma to zastosowanie dzisiaj)?

Zdaję sobie oczywiście sprawę, że ściślejsza granica byłaby bardziej idealna, gdybyś w jakiś sposób znała maksymalną długość struny. Ale jeśli używasz VARCHAR (255), prawdopodobnie oznacza to, że nie znasz maksymalnej długości, tylko że jest to „krótki” ciąg.

Uwaga: znalazłem to pytanie ( varchar (255) v tinyblob v tinytext ), które mówi, że VARCHAR ( n ) wymaga n +1 bajtów pamięci dla n <= 255, n +2 bajtów pamięci dla n > 255. Czy to jedyny powód? Wydaje się to dość arbitralne, ponieważ oszczędzałbyś tylko dwa bajty w porównaniu z VARCHAR (256), a równie łatwo mógłbyś zaoszczędzić kolejne dwa bajty, deklarując go jako VARCHAR (253).

— Wyrko
źródło

109

Historycznie, 255 znaków było często maksymalną długością a VARCHARw niektórych DBMS i czasami nadal kończy się to efektywnym maksimum, jeśli chcesz używać UTF-8 i mieć indeksowaną kolumnę (z powodu ograniczeń długości indeksu).

— chaos
źródło

4

@CharlesBretana: jeśli przeczytasz resztę cytowanego zdania, znajdziesz dokładne wyjaśnienie, o które prosisz.

— chaos

2

@CharlesBretana: Przez „fałszywy UTF-8” rozumiem kodowanie MySQL „utf8”, które, jak wspomniałem, rezerwuje (i jest ograniczone) 3 bajty na znak. To nie jest bardzo dobra wersja UTF-8; jeśli chcesz mieć przyzwoity UTF-8 w MySQL, musisz użyć jego kodowania "utf8mb4". Ale ludzie są dużo bardziej skłonni do tego nie wiedząc i idą z "utf8" i dużo bardziej chętni do kodowania UTF-8 niż jakiegokolwiek innego kodowania, więc, presto, kończą z maksymalną indeksowaną długością 255 znaków w VARCHAR. Pomimo twojego zdziwienia.

— chaos

3

@CharlesBretana: Wyjaśniłem to już trzy razy i nic się nie zmieniło. Limit długości indeksu MySQL nadal wynosi 767 bajtów, liczba bajtów potrzebnych do zakodowania 3-bajtowego znaku UTF-8 to nadal 3, a podłoga (767/3) to nadal 255. Twoja determinacja, aby znaleźć coś, co można pomylić z przekonaniem żebraków .

— chaos

1

@CharlesBretana (Przepraszam za spóźnienie na całą imprezę) Nie jestem specjalistą od DB, ale myślę, że chaos mówi: tak, kolumna „Fałszywy UTF-8” może mieć więcej niż 255 znaków, ale indeks będzie działa tylko na pierwszych 255 znakach zmiennej varchar, co oznacza, że jest to efektywne maksimum kolumny, jeśli chcesz, aby była w pełni indeksowana. Teraz to tylko to, co zrozumiałem z jego wyjaśnień, mogę się mylić, w ogóle nie jestem ekspertem w indeksach SQL.

— Francis Lord

2

@CharlesBretana Jeśli dobrze przyjrzysz się odpowiedzi Chaosa, zauważysz, że została ona podzielona na 2 części: 1. Historyczny powód, dla którego Varchar (255) jest tak powszechny (w niektórych starszych DBMS było to maksimum), 2. Nawet dzisiaj jest to nadal ograniczenie dla niektórych z powodu ograniczeń indeksu omówionych wcześniej, część 1 i 2 nie są połączone. Część 1 jest właściwą odpowiedzią na pytanie, część 2 to uwaga dodatkowa, która jest nadal aktualna w stosunku do pytania, ponieważ wyjaśnia, dlaczego nawet dzisiaj może to być ograniczenie. (CIĄG DALSZY ->)

— Francis Lord

161

255, ponieważ jest to największa liczba znaków, które można policzyć za pomocą liczby 8-bitowej. Maksymalizuje użycie 8-bitowego licznika, bez niepoważnego wymagania kolejnego całego bajtu do policzenia znaków powyżej 255.

Gdy jest używany w ten sposób, VarChar używa tylko liczby bajtów + 1 do przechowywania tekstu, więc równie dobrze możesz ustawić go na 255, chyba że chcesz mieć sztywny limit (na przykład 50) liczby znaków w polu.

— Robert Harvey
źródło

90

Podoba mi się to zdanie: „niepoważnie wymagający kolejnego całego bajtu”. =)

— MusiGenesis

7

Czy jest to prawdą w przypadku baz danych, w których varchary to UTF-8?

— antak

1

@antak: W MySQL, używając InnoDB, żadna kolumna klucza nie może być większa niż 767 bajtów. Jeśli kolumna VARCHAR to UTF8 (co oznacza, że każdy znak może zająć do 3 bajtów), maksymalna dozwolona długość kolumny to floor (767/3) = 255. Zakładam, że "767" zostało wybrane dokładnie z tego powodu.

— BlueRaja - Danny Pflughoeft

1

Jeśli zestawem znaków jestutf8 , varchar(85)jest granicą, powyżej której przecięcie kończy bajt długości z jednego do dwóch bajtów. Jeśli tak utf8mb4, to jest varchar(63). Są one istotne, ponieważ są maksymalnymi wartościami, do których można rozszerzyć długość VARCHAR za pomocą internetowego ALTER TABLE . W konsekwencji wyprowadziłem te liczby, tworząc tabelę z varchar(2) charset utf8kolumną i sprawdzając, jak dalece byłem w stanie ją rozszerzyć ALGORITHM=INPLACE.

— antak

Ma to jeszcze większy sens, jeśli weźmie się pod uwagę, że wiele „baz danych” było przechowywanych na taśmie magnetycznej. Bardzo często odczytywało się dane w „blokach”, których rozmiar był wielokrotnością dwóch. W ten sposób dane były przechowywane najbardziej wydajnie (a gdy działałeś na starym komputerze mainframe, małe wydajności, takie jak ta, były optymalizacjami typu „zrób to lub zepsuj”).

— TMN

23

Prawdopodobnie dlatego, że zarówno SQL Server, jak i Sybase (żeby wymienić dwa, które znam) miały kiedyś maksymalnie 255 znaków w liczbie znaków w VARCHARkolumnie. W przypadku SQL Server zmieniło się to w wersji 7 w latach 1996/1997 ... ale stare nawyki czasami ciężko umierają.

— Charles Bretana
źródło

8

+1 za cytowanie konkretnych baz danych i wersji. A „Stare nawyki umierają ciężko” to prawdopodobnie najprawdziwsza odpowiedź ze wszystkich.

— Andrew M

17

Odpowiem na dosłowne pytanie: nie , nie ma dobrego powodu, dla którego VARCHAR (255) jest używany tak często (rzeczywiście istnieją powody , jak omówiono w innych odpowiedziach, po prostu nie są dobre). Nie znajdziesz wielu przykładów projektów, które zakończyły się katastrofalną klęską, ponieważ architekt wybrał VARCHAR (300) zamiast VARCHAR (255). Byłby to problem prawie całkowicie nieistotny, nawet gdybyś mówił o CHAR zamiast VARCHAR.

— MusiGenesis
źródło

1 bajt z 255 to 0,4%. Czasami zależy ci na ostatnich pół procenta. Czasami nie. Jeśli koszty hostingu i perfekcji sięgają dziesiątek dolarów, prawdopodobnie nie obchodzi Cię to. Jeśli napotkają miliony, prawdopodobnie tak.

— Edward Brey,

2

@EdwardBrey: Jeśli Prawo Moore'a nadal jest prawdziwe, moja odpowiedź tutaj jest 16 razy bardziej aktualna niż wtedy, gdy ją pisałem.

— MusiGenesis

Chyba że odkryliśmy 16 razy więcej sposobów, w jakie komputery mogą nam pomóc. Szybkość wciąż jest cechą.

— Edward Brey,

14

Kiedy mówisz, 2^8że otrzymujesz 256, ale liczby w kategoriach komputerów zaczynają się od liczby 0. Więc masz 255, możesz sondować to w masce internetowej dla adresu IP lub w samym IP.

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

To pomaga?

— exec.-
źródło

1

W przypadku liczb całkowitych liczysz zaczynając od 0, a kończąc na 255. Ale z miejscami w ciągu liczysz zaczynając od 1 miejsca, więc nie ma sensu kończyć na 256 miejscu, ponieważ zaczynasz od 1 zamiast od 0? Nie zgadzam się jeszcze całkowicie z varchar (256) ze względu na wyniki string_length (), ale naprawdę nie jestem pewien.

— HoldOffHunger

1

Ciągi @HoldOffHunger w bazie danych mogą mieć długość zero znaków, więc dopuszczalny zakres długości, gdy długość jest przechowywana w ośmiu bitach, wynosi od 0 do 255. Jeśli chcesz powiedzieć, że wszystkie łańcuchy muszą mieć co najmniej jeden znak, może obsługiwać ciągi 256 znaków o długości ośmiu bitów.

— phoog

7

Uwaga: znalazłem to pytanie ( varchar (255) v tinyblob v tinytext ), które mówi, że VARCHAR ( n ) wymaga n +1 bajtów pamięci dla n <= 255, n +2 bajtów pamięci dla n > 255. Czy to jedyny powód? Wydaje się to dość arbitralne, ponieważ oszczędzałbyś tylko dwa bajty w porównaniu z VARCHAR (256), a równie łatwo mógłbyś zaoszczędzić kolejne dwa bajty, deklarując go jako VARCHAR (253).

Nie, nie oszczędzasz dwóch bajtów deklarując 253. Implementacja varchar to najprawdopodobniej licznik długości i niezakończona tablica o zmiennej długości. Oznacza to, że jeśli zapiszesz "hello" w varchar (255), zajmiesz 6 bajtów: jeden bajt na długość (cyfra 5) i 5 bajtów na pięć liter.

— Stefano Borini
źródło

3

To stwierdzenie nie dotyczy wszystkich baz danych. wiele baz danych używa pól varchar o podanym rozmiarze w tabelach, dzięki czemu nie muszą przenosić wierszy, gdy to pole zostanie zmienione dla wiersza.

— SingleNegationElimination

tak masz rację. zależy od implementacji. Musisz sprawdzić instrukcję dostawcy, aby zobaczyć, co się dzieje

— Stefano Borini,

2

Może to być dopuszczalne, ale implementacja w VARCHARten sposób podważa cały sens używania VARCHARzamiast CHAR.

— dan04

4

Liczba jednobajtowa bez znaku może zawierać zakres [0-255] włącznie. Więc kiedy widzisz 255, dzieje się tak głównie dlatego, że programiści myślą w bazie10 ( ?) :)

Właściwie przez chwilę 255 było największym rozmiarem, jaki można nadać VARCHAR w MySQL, a używanie VARCHAR zamiast TEXT przy indeksowaniu i innych problemach ma zalety.

— gahooa
źródło

4

W wielu aplikacjach, takich jak MsOffice (do wersji 2000 lub 2002), maksymalna liczba znaków na komórkę wynosiła 255. Przenoszenie danych z programów zdolnych do obsługi ponad 255 znaków na pole do / z tych aplikacji było koszmarem. Obecnie limit jest coraz mniej przeszkadzający.

— Joaquin Montes
źródło

2

0000 0000 -> to jest 8-bitowa liczba binarna. Cyfra oznacza trochę.

Liczysz tak:

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

Każdy bit może mieć jedną z dwóch wartości: włączony lub wyłączony. Całkowitą najwyższą liczbę można przedstawić przez pomnożenie:

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

Lub

2^8 - 1.

Odejmujemy jeden, ponieważ pierwsza liczba to 0.

255 może pomieścić całkiem sporo (bez zamiaru gry słów) wartości.

Gdy używamy większej liczby bitów, maksymalna wartość rośnie wykładniczo. Dlatego z wielu powodów dodawanie większej liczby bitów jest przesadą.

— ScottyBlades
źródło

1

Innym powodem może być to, że w bardzo starych bibliotekach dostępu do danych w systemie Windows, takich jak RDO i ADO (wersja COM nie ADO.NET), trzeba było wywołać specjalną metodę GetChunk, aby pobrać dane z kolumny zawierającej więcej niż 255 znaków. Jeśli ograniczyłeś kolumnę varchar do 255, ten dodatkowy kod nie był konieczny.

— Booji Boy
źródło