Gemäß der DNS-Spezifikation Die maximale Länge des Domainnamens beträgt :
255 * 3 =765 <767 (Nur knapp :-) )
Beachten Sie jedoch, dass jede Komponente nur 63 Zeichen lang sein darf.
Daher würde ich vorschlagen, die URL in die Komponentenbits zu zerhacken.
Mit http://foo. example.com/a/really/long/path?with=lots&of=query¶meters=that&goes=on&forever&and=ever
Wahrscheinlich wäre das angemessen:
- Protokoll-Flag ["http" -> 0 ] (speichere "http" als 0, "https" als 1 usw.)
- subdomain ["foo" ] ( 255 - 63 =192 Zeichen :Ich könnte 2 weitere abziehen, weil min tld 2 Zeichen lang ist )
- Domäne ["Beispiel"], ( 63 Zeichen )
- tld ["com"] ( 4 Zeichen für "info" tld )
- Pfad [ "ein/wirklich/langer/Pfad" ] ( so lange Sie wollen -in separater Tabelle speichern )
- queryparameters ["with=lots&of=query¶meters=that&goes=on&forever&and=ever" ] ( Speichern in einer separaten Schlüssel/Wert-Tabelle )
- Portnummer / Authentifizierungsmaterial, das selten verwendet wird, kann in einer separaten Schlüsseltabelle sein, wenn es tatsächlich benötigt wird.
Das gibt Ihnen einige nette Vorteile:
- Der Index bezieht sich nur auf die Teile der URL, die Sie durchsuchen müssen (kleinerer Index!)
- Abfragen können auf die verschiedenen URL-Teile beschränkt werden (zum Beispiel jede URL in der Facebook-Domain finden)
- Jede URL, die eine zu lange Subdomain/Domain hat, ist gefälscht
- einfach zu verwerfende Abfrageparameter.
- Einfache Suche nach Domainnamen/TLD ohne Berücksichtigung der Groß- und Kleinschreibung
- Verwerfen Sie die Syntax Sugar ( "://" nach dem Protokoll, "." zwischen Subdomain/Domain, Domain/TLD, "/" zwischen TLD und Pfad, "?" vor der Abfrage, "&" "=" in der Abfrage)
- Vermeidet das große Problem mit dünnen Tabellen. Die meisten URLs haben weder Abfrageparameter noch lange Pfade. Wenn sich diese Felder in einer separaten Tabelle befinden, wird Ihre Haupttabelle den Größentreffer nicht annehmen. Bei Abfragen passen mehr Datensätze in den Speicher, daher schnellere Abfrageleistung.
- (weitere Vorteile hier).
