2

複数のテーブルと外部キーをクエリするためのベスト プラクティスは何ですか?

例えば:

ユーザーには多くのタスクがあり、多くのリマインダーがあります

ベストプラクティスは、外部キーを直接の親戚に保持することです。つまり、次のようになります。

タスク テーブル: id、user_id

リマインダー テーブル: id、task_id

...テーブルをすべての可能な親戚に接続する外部キーがたくさんある状況を避けるため。

ユーザーのリマインダーをすべて取得したいとします。

SELECT reminders.* FROM users
LEFT JOIN tasks ON users.id = tasks.user_id
LEFT JOIN reminders ON tasks.id = reminders.task_id
WHERE tasks.user_id = {#YourUserIdVariable}

レコードを取得するために結合を行うことが、データベースの整合性を上回るポイントはありますか? (reminders.user_id を保存することがそもそも悪い実践であると仮定しますか?

5テーブル?10?

4

2 に答える 2

2

標準では、関係/結合によって導出される可能性のある冗長な外部キー情報など、不必要に冗長な情報を保存しないことになっています。

実際には、これは直接的な関係の FKey のみを格納し、セカンダリまたは暗黙の FKey 情報を格納しないことを意味します。パフォーマンス上の理由から、ある時点でリレーションを「ショートサーキット」しようとするかもしれませんが、技術的にはそれは非正規化の一種です。それを行うことはできますが、必要性が明らかな場合にのみ行う必要があります。つまり、適切な正規化が常にデフォルトである必要があり、それ以外はそれ自体を大幅に正当化する必要があります。

レコードを取得するために結合を行うことがデータベースの整合性を上回るポイントはありますか?」: おそらくですが、これはケースバイケースでしか判断できません。このようなビジネス上のトレードオフを、データのみの技術的ルールに還元することはできません。

于 2013-08-27T20:47:00.767 に答える
1

データベースに保存するデータ量はどれくらいですか? 結合の各テーブルに比較的少量の行がある場合、正規化されたデータベースと正規化されていないデータベース間の実行時間は無視できます。

したがって、代わりに、自分にとって意味のある設計を採用するだけで、意味のある場所でテーブルを正規化および非正規化できます。

この件に関する良い読み物は次のとおりです。 http://www.codinghorror.com/blog/2008/07/maybe-normalizing-isnt-normal.html

于 2013-08-27T20:20:19.980 に答える