DNS仕様 によると ドメイン名の最大長は次のとおりです：
255 * 3 =765 <767（かろうじて:-)）
ただし、各コンポーネントの長さは63文字のみであることに注意してください。
したがって、URLをコンポーネントビットに分割することをお勧めします。
おそらくこれで十分でしょう：
- プロトコルフラグ["http"->0]（ "http"を0として、 "https"を1として保存します。）
- subdomain ["foo"]（255-63 =192文字：min tldは2文字なので、さらに2を引くことができます）
- domain ["example"]、（63文字）
- tld ["com"]（ "info" tldを処理するための4文字）
- path ["a / really / long / path"]（必要な限り-別のテーブルに保存 ）
- queryparameters ["with =lots＆of =query＆parameters =that＆goes =on＆forever＆and =ever"]（別のキー/値テーブルに保存 ）
- めったに使用されないポート番号/認証のものは、実際に必要な場合は別のキー付きテーブルに含めることができます。
これにより、いくつかの優れた利点が得られます：
- インデックスは、検索する必要のあるURLの部分にのみあります（小さいインデックス！）
- クエリはさまざまなURL部分に制限できます（たとえば、FacebookドメインですべてのURLを検索します）
- サブドメイン/ドメインが長すぎるURLは偽物です
- クエリパラメータを簡単に破棄できます。
- 大文字と小文字を区別しないドメイン名/tld検索を簡単に実行
- シンタックスシュガーを破棄します（プロトコルの後の「：//」、サブドメイン/ドメイン間の「。」、ドメイン/ tld、tldとパス間の「/」、クエリの前の「？」、「＆」「=」クエリ）
- 主要なスパーステーブルの問題を回避します。ほとんどのURLには、クエリパラメータも長いパスもありません。これらのフィールドが別のテーブルにある場合、メインテーブルはサイズに影響しません。クエリを実行すると、より多くのレコードがメモリに収まるため、クエリのパフォーマンスが向上します。
- （ここでより多くの利点）