2

MySQL（InnoDB）にユーザーアイテムでいっぱいのテーブルがあります。基本的に、各行にはuser_idフィールドとcolorなどの他のアイテムプロパティがあります。次に、他のユーザーのアイテムのIDを保持するリンクと呼ばれるフィールドがもう1つありますが、ほとんどの場合（90％）はリンクされていないため、フィールドはに設定されNULLます。

フィールドリンクを設定する600万行の90％を使用するよりも、リンク情報を保持する新しいテーブルを作成する方が効率的でしょうか。NULL

Hibernateを使用しています。

4

4 に答える 4

2

はい、それはより効率的でしょう。それは非常に小さな違いを生むでしょう。

最善の方法は、自分にとって最も簡単なことを行い、それが実際の問題になったときに変更することです。

于 2011-06-21T19:03:43.180 に答える
1

はい、それはより効率的でより正規化されます。このようなnullがたくさんあるテーブルを見ると、正規化の候補と見なされます。この例では、その列をテーブルから完全に削除することができ、よりクリーンで保守が容易になります。ユーザーアイテムテーブルの外部キーである2つのuser_idを使用してジャンクションテーブルを作成するだけです。

于 2011-06-21T19:11:09.517 に答える
0

ロジックに関する限り、リンクデータを含むテーブルのみを格納することを検討してください。また、ifを呼び出すコードは、「nullでない場合」または同等の処理を実行して、常に何を取得するかを知ることができます。より適切な仮定を立てることができる場合は、これらのnullをすべて保存しないでください

于 2011-06-21T19:04:57.707 に答える
0

占有するスペースが少なくなります。ただし、クエリごとに（左）JOINを実行すると、パフォーマンスが低下します。特に、行が多く、テーブルがメモリに収まらない場合はなおさらです。次に、1つのレコードをフェッチするために2つのディスクシークが必要です。

更新：

  • JOINは追加の処理を行います。インデックスがある場合は高速になりますが、それでも別のレコードを検索する必要があります。また、トランザクションをサポートするためにInnoDBを使用する場合、データベースは結合されたレコードのバージョンを維持する必要があります。
  • JOINはメモリの局所性に悪影響を及ぼします。今度は、まったく異なるメモリ位置にあるレコードを検索する必要があります。
  • 前述したように、データがメモリにない場合は、追加のディスクシークが必要です。これは本当に悪いです。
于 2011-06-21T19:08:01.457 に答える