Ifølge DNS-specifikationen den maksimale længde af domænenavnet er:
255 * 3 =765 <767 (bare knap :-) )
Bemærk dog, at hver komponent kun kan være på 63 tegn.
Så jeg vil foreslå, at du hugger url'en ind i komponentbits.
Brug af http://foo. example.com/a/really/long/path?with=lots&of=query¶meters=that&goes=on&forever&and=ever
Dette ville sandsynligvis være tilstrækkeligt:
- protokolflag ["http" -> 0 ] (gem "http" som 0, "https" som 1 osv. )
- underdomæne ["foo" ] ( 255 - 63 =192 tegn :Jeg kunne trække 2 mere fra, fordi min tld er 2 tegn )
- domæne ["eksempel"], ( 63 tegn )
- tld ["com"] ( 4 tegn til at håndtere "info" tld )
- sti [ "en/virkelig/lang/sti" ] (så længe du vil -gem i en separat tabel )
- forespørgselsparametre ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( gem i en separat nøgle-/værditabel )
- portnummer / godkendelsesting, der sjældent bruges, kan være i en separat nøgletabel, hvis det faktisk er nødvendigt.
Dette giver dig nogle gode fordele:
- Indekset er kun på de dele af url'en, som du skal søge på (mindre indeks! )
- forespørgsler kan begrænses til de forskellige url-dele (find f.eks. hver url i facebook-domænet )
- alt url, der har et for langt underdomæne/domæne, er falsk
- let at kassere forespørgselsparametre.
- nem at udføre store og små bogstaver i domænenavn/tld-søgning
- kasser syntakssukkeret ( "://" efter protokol, "." mellem underdomæne/domæne, domæne/tld, "/" mellem tld og sti, "?" før forespørgsel, "&" "=" i forespørgsel)
- Undgår det store sparsomme bordproblem. De fleste webadresser vil ikke have forespørgselsparametre eller lange stier. Hvis disse felter er i en separat tabel, vil din hovedtabel ikke tage størrelsen. Når du laver forespørgsler, vil flere registreringer passe ind i hukommelsen, derfor hurtigere forespørgselsydeevne.
- (flere fordele her).