Czy powinienem dodać dowolny limit długości do kolumn VARCHAR?

Według dokumentacji PostgreSQL nie ma różnicy w wydajności między VARCHAR, VARCHAR(n)a TEXT.

Czy powinienem dodać dowolny limit długości do kolumny nazwy lub adresu ?

Edycja: brak duplikatu:

• Gdyby wszystkie wartości miały 36 znaków, wyszukiwanie indeksu byłoby zauważalnie szybsze przy użyciu char vs varchar

Wiem, że ten CHARtyp jest reliktem przeszłości i interesuję się nie tylko wydajnością, ale innymi zaletami i wadami, takimi jak Erwin w swojej niesamowitej odpowiedzi.

Odpowiedź brzmi nie .
Nie dodawaj modyfikatora długości, varcharjeśli możesz tego uniknąć. W większości przypadków tak naprawdę nie potrzebujesz ograniczenia długości. Po prostu użyj textdla wszystkich danych postaci. Zrób to varchar(bez modyfikatora długości), jeśli chcesz zachować zgodność z RDBMS, który nie ma text.

Wydajność jest prawie taka sama - w rzadkich sytuacjachtext jest nieco szybsza , a cykle zapisujesz na sprawdzenie długości.

Jeśli faktycznie potrzebujesz wymusić maksymalną długość, nadal używaj texti dodaj ograniczenie sprawdzania :

ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 51);

Możesz zmodyfikować lub usunąć takie ograniczenie w dowolnym momencie, bez konieczności wprowadzania zmian w definicji tabeli i wszystkich zależnych obiektach (widoki, funkcje, klucze obce, ...)

Dzięki modyfikatorom długości po prostu napotykasz problemy takie jak ta czy ta czy ta ...

PostgreSQL 9.1 wprowadził nową funkcję, która nieco łagodzi ból. Przytaczam tutaj informacje o wydaniu :

Pozwól ALTER TABLE ... SET DATA TYPEuniknąć przepisywania tabel w odpowiednich przypadkach (Noah Misch, Robert Haas)

Na przykład konwersja varcharkolumny na tekst nie wymaga już przepisania tabeli. Jednak zwiększenie ograniczenia długości varcharkolumny nadal wymaga przepisania tabeli.

Jeśli widzisz limit długości jako rodzaj ograniczenia sprawdzania, aby upewnić się, że sprawdzasz poprawność danych, to tak, dodaj go. Właściwie możesz nie używać określenia długości, lecz realne ograniczenia wyboru zamiast tego dokonać zmieniając limit szybciej.

Aby zmienić (zwiększyć) limit długości, musisz uruchomić taki, ALTER TABLEktóry może zająć dużo czasu (ze względu na możliwe ponowne zapisanie tabeli), podczas którego konieczna jest wyłączna blokada stołu.

Zmiana (tj. Upuszczenie i ponowne utworzenie) ograniczenia sprawdzania jest bardzo krótką operacją i wymaga jedynie odczytu danych tabeli, nie zmieni żadnych wierszy. Będzie to o wiele szybsze (co z kolei oznacza, że ​​wyłączna blokada stołu będzie utrzymywana przez znacznie krótszy czas).

Podczas pracy nie ma żadnej różnicy między a text, a varcharlub varchar(5000)kolumną.

Pytanie dotyczy w szczególności tego, czy dodanie dowolnego limitu długości do kolumn VARCHAR?

Na to odpowiedź brzmi „nie”. Nic nie usprawiedliwia dodania arbitralnego limitu, tak jak w gorszych bazach danych, które obsługują varchar(max)lub używają takich konwencji varchar(255). Jeśli jednak specyfikacja dotyczy limitu, myślę, że odpowiedź staje się znacznie bardziej złożona, szczególnie w przypadku nowoczesnych wersji PostgreSQL. I do tego skłaniałbym się ku TAK .

Moim zdaniem limit jest rozsądnym wyborem, jeśli wymaga tego specyfikacja. Zwłaszcza w przypadku bardziej rozsądnych obciążeń. Jeśli nie z innego powodu, to w celu zachowania metadanych.

Z mojej odpowiedzi tutaj, wydajność indeksu dla CHAR vs VARCHAR (Postgres) , gdzie odnoszę się do wartości metadanych.

Gdybym znalazł specyfikację z kluczami tekstowymi o zmiennej długości, które były znaczące i której ufałem, że będę mieć stałą maksymalną długość, też bym użył varchar. Nie mogę jednak wymyślić niczego, co spełniałoby te kryteria.

Wygląda na to, że może występować pewna różnica w wydajności, jeśli VARCHARjest regularnie używana do przechowywania bardzo dużych ciągów, ponieważ „długie ciągi są automatycznie kompresowane przez system”, a „bardzo długie wartości są również przechowywane w tabelach w tle”. Teoretycznie oznaczałoby to, że duża liczba żądań dla bardzo długiego pola łańcuchowego byłaby wolniejsza niż dla pola krótkiego łańcucha. Prawdopodobnie nigdy nie napotkasz tego problemu, ponieważ nazwy i adresy nie będą bardzo długie.

Jednak w zależności od tego, jak używasz tych ciągów poza bazą danych, możesz chcieć dodać praktyczny limit, aby zapobiec nadużyciom systemu. Na przykład, jeśli gdzieś wyświetlasz nazwę i adres w formularzu, możesz nie być w stanie wyświetlić całego akapitu tekstu w polu „nazwa”, więc sensowne byłoby ograniczenie kolumny nazwy do około 500 postacie.