私は、年間200万行の予測負荷を持つ、提出されたアプリケーションフォームのデータを含むデータベーステーブルを持っています。別のテーブルのnullableデータベース属性
アプリケーションにカスタムテキストをタグ付けするオプションがありますが、この機能はおそらく5〜10％の時間しか使用されません。後でこのテキストでフォームを検索することができます。
これは、メインテーブルのnullable属性として実装する必要がありますか、キーとテキストだけを含む別のテーブルにこれを抽出する方が良いでしょうか？
）別表
2に移動した場合はNULL可能ではありません）これは、意味的に
3よりエレガントである）意志をバック参加あなたが親テーブルのPKに参加し、すべての確率でハッシュ結合を使用するので非効率ではありません。
4）今後、各アプリケーションでこのようなオプションの列をさらに増やすことにした方が拡張性があります。
アプリケーション（アプリの＃、日付、...）
Application_Attachments（アプリの＃、text_col1）
おそらく答えは使用する特定のDBMSによって決まります。たとえば、NULLテキスト列がDBMS上で占有する領域はどれくらいですか？また、このテキスト列はどれくらいの大きさですか？数文字だけですか？
テキスト用に別のテーブルを使用する利点の1つは、フルテーブルスキャンが必要な場合は、テキストベースの検索で効率的である可能性があるということです。（これは、これらの行は、単一の表よりも小さくなります）。ただし、他のデータを取得するためにメインテーブルに戻って結合する必要があるという事実とのバランスをとる必要があります。
唯一の方法は、両方向に設定してベンチマークすることです。別のテーブル内のNULL可能文字列が多くの方法
1で良いだろう持つ
独自のテーブルにならない古典的な例は、 Middle_Initial char（1）です。 –
"より良い"： 次のようなデザインで見ることができますか？あなたは最適化しようとしているものを提供できますか？ 「より良い」はあいまいです。何かが「より良い」ものになる可能性があります。あなたにとって重要なのは何ですか？ –
さて、2つのテーブルはより複雑に見えますが、ヌル値を持つ行の90％を避けるために冗長性が少なくなっています。これらのテキストを検索することは、別のテーブルに置いた方が簡単かもしれません。しかし、再度、ヌル属性をメインテーブルに置くことはより簡単に思えるかもしれませんが、データベースの設計が不良であると考えられます。 – lox