〜60,000行の静的データベースがあります。~30,000 の一意のエントリがある特定の列があります。その比率 (60,000 行/特定の列の 30,000 の一意のエントリ) を考えると、それらのエントリを含む新しいテーブルを作成し、メイン テーブルからそれにリンクする価値はありますか? それとも、それは価値があるよりも多くの問題になるでしょうか?
質問をより具体的に言えば、このフィールドを独自のテーブルに分離することで、より多くの効率が得られるでしょうか?
** アップデート **
ここでは VARCHAR(100) フィールドについて話していますが、実際には、どのエントリもそれほど多くのスペースを使用しているとは思えません。VARCHAR(50) に切り詰めることができるでしょう。エントリ例: 「ガスパッチとリトルカナダ」および「Kora Temple Masonic Bldg. George Coombs」
フィールドが通常約 30 文字を含む VARCHAR(255) であり、代わりにメイン テーブルに 4 バイト整数を格納し、4 バイト整数と VARCHAR(255) を含む 2 番目のテーブルを使用する場合、あなたはいくつかの省スペースを見ています。
古いスキーム:
T1: 30 bytes * 60 K entries = 1800 KiB.
新しいスキーム:
T1: 4 bytes * 60 K entries = 240 KiB
T2: (4 + 30) bytes * 30 K entries = 1020 KiB
つまり、大雑把に 1800 - 1260 = 540 KiB のスペース節約になります。必要に応じて、T2 の整数列にインデックスを作成すると、スペースがいくらか失われます。データの平均長が 30 バイトを超えると、スペースの節約が増加します。繰り返される行の比率が増加すると、節約が増加します。
スペースの節約が重要かどうかは、コンテキストによって異なります。さらに 0.5 メガバイトのメモリが必要な場合は、それが必要です。4 バイト整数 (120 + 960 KiB = 1080 KiB; 720 KiB 節約)。一方、利用可能な数ギガバイトのストレージの半分のメガバイトに本当に気付かない場合は、より実用的な問題になります. 2 つのテーブルを維持するのは大変な作業ですが、使用するたびに名前が同じであることを保証します。1 つのテーブルを維持するということは、名前のペアが正しく処理されていることを確認する必要があることを意味します。または、その可能性を無視して、ペアを持つべき場所でペアがないか、あるべき場所でトリプレットになってしまう可能性が高いです。ダブルトン。
明らかに、繰り返される型が 4 バイトの整数である場合、2 つのテーブルを使用しても何も保存されません。スペースがかかります。
したがって、多くのことは、あなたが私たちに伝えていないことに依存しています。タイプは重要な問題の 1 つです。もう 1 つは、繰り返しの背後にあるセマンティクスです。