2015-04-10 10 views
5

Wydaje się, że lepiej jest używać typu danych TEXT, jeśli korzystasz z PostgreSQL (lub innych baz danych, które obsługują to również), a nie character varying(NN), ponieważ nie ma kary za wydajność, a maksymalna możliwa długość może być regulowana poprzez zrzucanie i ponowne stosowanie wiązań bez wpływania na widoki itp., które wykorzystują pole.Jak dodać ograniczenie długości do pola tekstowego

Ale, jak ten stosowany jest przymus (kod SQL)?

Aha, i myślę, że mądrze jest pominąć nazwę podczas dodawania wiązania za pomocą narzędzia takiego jak pgAdmin, aby pozwolić mu wybrać sam.

+0

Ale to kolumna tekstu o długości check przymusu naprawdę bardziej efektywne niż nvarchar? – jarlh

+0

@jarlh Postgres nie ma 'nvarchar'a –

+0

@jarlh Zobacz http://www.postgresql.org/docs/current/interactive/datatype-character.html "Wskazówka: Nie ma żadnej różnicy w wydajności między tymi trzema typami, oprócz zwiększonej przestrzeni dyskowej, gdy używa się typu z pustym materiałem i kilku dodatkowych cykli procesora, aby sprawdzić długość podczas przechowywania w kolumnie o ograniczonej długości." – IMSoP

Odpowiedz

12

Po utworzeniu tabeli można zrobić coś tego rodzaju,

CREATE TABLE names (
    name text CHECK namechk (char_length(name) <= 255) 
) 

(namechk jest tylko nazwa przymusu)

samo dotyczy ALTER TABLE na przykład:

ALTER TABLE names 
    ADD CONSTRAINT namechk CHECK (char_length(name) <= 255); 
+1

Czy to ważne, czy używam 'char_length' lub' length'? W międzyczasie zastosowałem ograniczenia używając tego ostatniego ... – Tobias

+1

Porównanie powinno oczywiście wynosić '<= 255". – Tobias

+0

'BŁĄD: błąd składniowy w lub w pobliżu" namechk "' Wygląda na to, że nie można podać nazwy ograniczenia, jeśli zostanie określone przy tworzeniu tabeli. – deFreitas

2

są naprawdę trzy rzeczy tutaj:

  1. Czy lepiej używać text + ograniczenia sprawdzającego lub varchar(N)?
  2. Jak napisać odpowiednie ograniczenie sprawdzające?
  3. Czy należy podać ograniczenia lub zezwolić na przypisanie automatycznej nazwy?

Odpowiedzi:

  1. varchar(N) będzie bardziej oczywiste podczas inspekcji schematu, a co programiści pochodzące z innych DB będzie spodziewać. Jednak, jak mówisz, trudniej jest później zmienić. Należy pamiętać, że zastosowanie nowego/zmodyfikowanego ograniczenia sprawdzającego nie jest wolne - wszystkie istniejące wiersze muszą być sprawdzone względem ograniczenia, tak więc na dużej tabeli konieczne jest wiele odczytów.
  2. Składnia ograniczenia sprawdzającego to CONSTRAINT name CHECK (condition) (lub tylko CHECK (condition), a Postgres sam wymyśli nazwę) w oświadczeniu CREATE TABLE i ALTER TABLE table_name ADD CONSTRAINT name CHECK (condition);. condition byłby wyrażeniem używającym odpowiedniego string function, np. char_length(foo) <= 255.
  3. Dodanie nazwy ograniczenia jest bardzo przydatne, jeśli chcesz później zarządzać ograniczeniem. W szczególności, ponieważ używasz tego do elastyczności, możesz chcieć napisać kod, aby usunąć i ponownie utworzyć wiązanie o nowej długości. Jeśli używasz tylko narzędzi graficznych, nie stanowi to problemu, ale zarządzanie wieloma serwerami (np. Tworzenie, testowanie i kopie produkcyjne) staje się o wiele łatwiejsze, jeśli możesz skryptować zmiany. O nazwie przymusu, byłoby to jak ALTER TABLE foo DROP CONSTRAINT ck_bar_length; ALTER TABLE foo ADD CONSTRAINT ck_bar_length CHECK (char_length(bar) <= 100); nie mogę faktycznie pomyśleć o niekorzyść nazywania swoje ograniczenia.
+0

Tak, oczywiście ograniczenie powinno mieć nazwę; właśnie dlatego powiedziałem "podczas dodawania za pomocą narzędzia takiego jak pgAdmin" (które buduje nazwę zgodnie ze schematem, który jest prawdopodobnie przydatny do naśladowania). – Tobias

+0

@Tobias Każde używane narzędzie utworzy je z * pewną * nazwą, wygenerowaną według jakiegoś algorytmu. Nie jest jednak * gwarantowane * używanie tej samej nazwy, gdy prowadzisz w różnych miejscach o różnych porach. Szczerze mówiąc nie mogę wymyślić powodu, by nie używać własnego nazwiska. – IMSoP

+0

Nie potrzebuję takiej gwarancji. Korzystałbym z interaktywnego narzędzia * raz *, a następnie użyłbym wygenerowanego kodu SQL do zastosowania tych samych zmian w innych miejscach, jeśli to konieczne, lub zapisania ich w plikach. – Tobias