Najlepszy typ pola bazy danych dla adresu URL

Muszę przechowywać adres URL w tabeli MySQL. Jaka jest najlepsza praktyka definiowania pola, które będzie zawierało adres URL o nieokreślonej długości?

1. Najniższa wspólna mianownik maksymalna długość adresu URL wśród popularnych przeglądarek internetowych: 2083 (Internet Explorer)

2. http://dev.mysql.com/doc/refman/5.0/en/char.html
   Wartości w kolumnach VARCHAR są łańcuchami o zmiennej długości. Długość można określić jako wartość od 0 do 255 przed MySQL 5.0.3 i od 0 do 65 535 w 5.0.3 i nowszych wersjach. Efektywna maksymalna długość zmiennej VARCHAR w MySQL 5.0.3 i nowszych zależy od maksymalnego rozmiaru wiersza (65 535 bajtów, który jest współużytkowany przez wszystkie kolumny) i użytego zestawu znaków.

3. Więc ...
   <MySQL 5.0.3 użyj TEXT
   lub
   > = MySQL 5.0.3 użyj VARCHAR (2083)

VARCHAR(512)(lub podobny) powinien wystarczyć. Ponieważ jednak tak naprawdę nie znasz maksymalnej długości danych adresów URL, mogę przejść bezpośrednio do TEXT. Niebezpieczeństwem tego jest oczywiście utrata wydajności ze względu na to, CLOBże jest on znacznie wolniejszy niż prosty typ danych typu string VARCHAR.

varchar(max) dla SQLServer2005

varchar(65535) dla MySQL 5.0.3 i nowszych

Spowoduje to alokację przestrzeni dyskowej w razie potrzeby i nie powinno wpłynąć na wydajność.

Będziesz chciał wybrać między kolumną TEKST lub VARCHAR na podstawie częstotliwości używania adresu URL i tego, czy rzeczywiście potrzebujemy długość być niezwiązany.

Użyj VARCHAR z maxlength> = 2083, jak sugerował micahwittman , jeśli:

1. Użyjesz wielu adresów URL na zapytanie (w przeciwieństwie do kolumn TEKSTOWYCH, zmienne VARCHAR są przechowywane w wierszu)
2. Jesteś pewien, że adres URL nigdy nie przekroczy limitu wiersza 65 535 bajtów.

Użyj TEKSTU, jeśli:

1. Adres URL naprawdę może przekroczyć limit 65 535 bajtów
2. Twoje zapytania nie wybiorą ani nie zaktualizują wielu adresów URL jednocześnie (lub bardzo często). Wynika to z tego, że kolumny TEKSTOWE po prostu trzymają wskaźnik w linii, a losowe dostępy związane z wyszukiwaniem danych odniesienia mogą być bolesne.

Powinieneś używać VARCHAR z kodowaniem znaków ASCII. Adresy URL są zakodowane w procentach, a międzynarodowe nazwy domen używają punycode, więc ASCII wystarczy do ich przechowywania. To zajmie znacznie mniej miejsca niż UTF8.

VARCHAR(512) CHARACTER SET 'ascii' COLLATE 'ascii_general_ci' NOT NULL

To naprawdę zależy od twojego przypadku użycia (patrz niżej), ale przechowywanie tak jak TEXTma problemy z wydajnością, a w VARCHARwiększości przypadków brzmi jak przesada.

Moje podejście: używaj hojnej, ale nieuzasadnionej dużej VARCHARdługości, takiej jak ta VARCHAR(500), i zachęcaj użytkowników, którzy potrzebują większego adresu URL, do korzystania z skracacza URL, takiego jak safe.mn.

Podejście do Twittera: Aby uzyskać naprawdę ładny UX, zapewnij automatyczny skrót do zbyt długich adresów URL i zapisz „wersję wyświetlaną” linku jako fragment adresu URL z elipsami na końcu. (Przykład: http://stackoverflow.com/q/219569/1235702byłby wyświetlany jako stackoverflow.com/q/21956...i prowadziłby do skróconego adresu URL http://ex.ampl/e1234)

Uwagi i zastrzeżenia

• Oczywiście podejście na Twitterze jest ładniejsze, ale dla potrzeb mojej aplikacji wystarczyło skrócenie adresu URL.
• Skracacze adresów URL mają swoje wady, takie jak problemy związane z bezpieczeństwem. W moim przypadku nie stanowi to dużego ryzyka, ponieważ adresy URL nie są publiczne i nie są często używane; jednak to oczywiście nie zadziała dla wszystkich. Wygląda na to, że safe.mn blokuje wiele adresów spamowych i phishingowych, ale nadal zalecałbym ostrożność.
• Pamiętaj, że nie powinieneś zmuszać użytkowników do używania skracacza URL. W większości przypadków (przynajmniej na potrzeby mojej aplikacji) 500 znaków jest zbyt wystarczające do tego, do czego większość użytkowników będzie go używać. Używaj / polecaj skracacz URL tylko w przypadku zbyt długich linków.

Większość przeglądarek pozwala na umieszczanie bardzo dużych ilości danych w adresie URL, a zatem wiele rzeczy kończy się tworzeniem bardzo dużych adresów URL, więc jeśli mówisz o czymś więcej niż część adresu URL domeny, musisz użyć kolumny TEKST, ponieważ VARCHAR / CHAR są ograniczone .

Nie wiem o innych przeglądarkach, ale IE7 ma limit 2083 znaków dla operacji HTTP GET . O ile żadne inne przeglądarki nie mają niższych limitów, nie rozumiem, dlaczego potrzebujesz więcej znaków niż 2083.

Większość serwerów WWW ma limit długości adresu URL (dlatego istnieje kod błędu dla „URI za długi”), co oznacza, że ​​istnieje praktyczny większy rozmiar. Znajdź domyślny limit długości dla najpopularniejszych serwerów internetowych i użyj największego z nich jako maksymalnego rozmiaru pola; powinno wystarczyć.

Lepiej użyj varchar (max), co (pod względem wielkości) oznacza varchar (65535). Spowoduje to nawet przechowywanie twoich większych adresów internetowych, a także pozwoli zaoszczędzić miejsce.

Specyfikator max rozszerza możliwości przechowywania typów danych varchar, nvarchar i varbinary. varchar (max), nvarchar (max) i varbinary (max) są wspólnie nazywane typami danych o dużej wartości. Za pomocą typów danych o dużej wartości można przechowywać do 2 ^ 31-1 bajtów danych.

Zobacz ten artykuł w witrynie TechNet na temat korzystania z typów danych o dużej wartości