Enligt DNS-specifikationen den maximala längden på domännamnet är:
255 * 3 =765 <767 (Bara knappt :-) )
Observera dock att varje komponent bara kan vara 63 tecken lång.
Så jag skulle föreslå att du hackar webbadressen i komponentbitarna.
Använder http://foo. example.com/a/really/long/path?with=lots&of=query¶meters=that&goes=on&forever&and=ever
Förmodligen skulle detta vara tillräckligt:
- protokollflagga ["http" -> 0 ] (lagra "http" som 0, "https" som 1, etc. )
- underdomän ["foo" ] ( 255 - 63 =192 tecken :Jag skulle kunna subtrahera 2 till eftersom min tld är 2 tecken )
- domän ["exempel"], ( 63 tecken )
- tld ["com"] ( 4 tecken för att hantera "info" tld )
- sökväg [ "en/verkligt/lång/sökväg" ] (så länge du vill -lagra i en separat tabell )
- frågeparametrar ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( lagra i en separat nyckel-/värdetabell )
- portnummer/autentiseringsgrejer som sällan används kan finnas i en separat nyckeltabell om det verkligen behövs.
Detta ger dig några fina fördelar:
- Indexet finns bara på de delar av webbadressen som du behöver söka på (mindre index! )
- frågor kan begränsas till de olika url-delarna (finn till exempel varje url i facebook-domänen )
- allt url som har en för lång underdomän/domän är falskt
- lätt att ignorera frågeparametrar.
- lätt att göra skiftlägesokänslig sökning av domännamn/tld
- kassera syntaxen sugar ( "://" efter protokoll, "." mellan underdomän/domän, domän/tld, "/" mellan tld och sökväg, "?" före fråga, "&" "=" i fråga)
- Undviker det stora problemet med glesa bord. De flesta webbadresser kommer inte att ha frågeparametrar eller långa sökvägar. Om dessa fält är i en separat tabell kommer din huvudtabell inte att ta storleksträffen. När du gör förfrågningar kommer fler poster att passa in i minnet, därför snabbare frågeprestanda.
- (fler fördelar här).