Volgens de DNS-specificatie de maximale lengte van de domeinnaam is:
255 * 3 =765 <767 (nauwelijks :-) )
Merk echter op dat elk onderdeel slechts 63 tekens lang kan zijn.
Dus ik zou willen voorstellen om de url in de componentbits te hakken.
Waarschijnlijk zou dit voldoende zijn:
- protocolvlag ["http" -> 0 ] ( sla "http" op als 0, "https" als 1, enz. )
- subdomein ["foo" ] ( 255 - 63 =192 tekens :ik zou er nog 2 kunnen aftrekken omdat min tld 2 tekens is )
- domein ["voorbeeld"], ( 63 tekens )
- tld ["com"] (4 tekens om "info" tld te verwerken)
- pad [ "a/real/long/path" ] ( zo lang als je wilt -opslaan in een aparte tabel )
- queryparameters ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( opslaan in een aparte sleutel/waarde-tabel )
- poortnummer / authenticatie-dingen die zelden worden gebruikt, kunnen indien nodig in een aparte tabel met sleutels staan.
Dit geeft je een aantal leuke voordelen:
- De index staat alleen op de delen van de url waar je op moet zoeken (kleinere index! )
- query's kunnen worden beperkt tot de verschillende url-delen (vind bijvoorbeeld elke url in het facebook-domein)
- elke url met een te lang subdomein/domein is nep
- gemakkelijk te negeren queryparameters.
- eenvoudig uit te voeren hoofdletterongevoelige domeinnaam/tld zoeken
- gooi de syntaxissuiker weg ("://" na protocol, "." tussen subdomein/domein, domein/tld, "/" tussen tld en pad, "?" voor query, "&" "=" in de vraag)
- Vermijdt het grote probleem met schaarse tabellen. De meeste url's hebben geen queryparameters of lange paden. Als deze velden in een aparte tabel staan, zal uw hoofdtabel de groottehit niet krijgen. Bij het uitvoeren van query's passen er meer records in het geheugen, dus snellere queryprestaties.
- (meer voordelen hier).