Zgodnie ze specyfikacją DNS maksymalna długość nazwy domeny to :
255 * 3 =765 <767 (tylko ledwie :-)) )
Zauważ jednak, że każdy komponent może mieć tylko 63 znaki.
Sugerowałbym więc pocięcie adresu URL na części składowe.
Używając http://foo. example.com/a/really/long/path?with=lots&of=query¶meters=that&goes=on&forever&and=ever
Prawdopodobnie byłoby to wystarczające:
- flaga protokołu ["http" -> 0] ( zapisz "http" jako 0, "https" jako 1 itd.)
- subdomena ["foo"] (255 - 63 =192 znaki:mógłbym odjąć jeszcze 2, ponieważ min tld to 2 znaki)
- domena ["przykład"], ( 63 znaki )
- tld ["com"] (4 znaki do obsługi "info" tld)
- ścieżka [ "a/really/long/path" ] ( tak długo, jak chcesz -zachowaj w osobnej tabeli )
- queryparameters ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( przechowuj w osobnej tabeli klucz/wartość )
- Rzadko używane informacje o numerze portu / uwierzytelnianiu mogą znajdować się w oddzielnej tabeli z kluczami, jeśli jest to rzeczywiście potrzebne.
Daje to kilka fajnych korzyści:
- Indeks znajduje się tylko w tych częściach adresu URL, które chcesz wyszukać (mniejszy indeks!)
- zapytania mogą być ograniczone do różnych części adresu URL (na przykład znajdź każdy adres URL w domenie facebook)
- każdy adres URL, który ma zbyt długą subdomenę/domenę, jest fałszywy
- łatwe do odrzucenia parametrów zapytania.
- łatwe do wykonania wyszukiwanie nazw domen/tld bez uwzględniania wielkości liter
- odrzuć cukier składni ( „://” po protokole, „.” między subdomeną/domeną, domeną/tld, „/” między tld a ścieżką, „?” przed zapytaniem, „&” „=” w zapytanie)
- Unika głównego problemu z rzadkimi tabelami. Większość adresów URL nie ma parametrów zapytania ani długich ścieżek. Jeśli te pola znajdują się w osobnej tabeli, główna tabela nie przyjmie trafionego rozmiaru. Podczas wykonywania zapytań do pamięci zmieści się więcej rekordów, a tym samym szybsza wydajność zapytań.
- (więcej zalet tutaj).
