データベース設計で 1 対 1 の関係を使用する必要があるのはいつですか? 私の意見では、2 つのテーブルが 1 対 1 の関係にある場合、それらを 1 つのテーブルに結合できます。これは本当ですか?
4 に答える
I/O とキャッシュの要件を軽減するための大きなテーブルの垂直分割 - クエリが頻繁に行われる列とめったに行われない列を分離します。
alter table
「コストが高すぎる」場合に、実動システムに列を追加する。スーパータイプ/サブタイプパターン。
テーブル (結合) の除去の恩恵を受ける垂直パーティショニング - オプティマイザーを提供することでそれがサポートされます (これも I/O とキャッシュを削減するためです)。
アンカー モデリング- 4 に似ていますが、 6NFまで下がります。
場合によっては、テーブル ロックに役立ちます。データベースに列を追加すると、完全に書き換えられるまでテーブル全体がロックされます。データベースに 10 万行ある場合、これはほとんどまたはまったく影響しません。しかし、1 億行または 10 億行の場合は、まったく別の話です...
また、スペースを取りすぎるデッド行を避けるのにも役立ちます。MVCCを使用していて、一部の列が定期的に上書きされる場合は、それらを別のテーブルに配置することが理にかなっている場合があります。間違いなく、自動バキュームが最終的に開始されますが、ハード ドライブの作業を節約するために、テキスト、varchar(n) などでいっぱいの行全体の束全体よりも、別のテーブルのいくつかの int フィールドをバキュームする方が適切です。
最後の理由はselect *
、ORM での悪用です。たとえば、画像やブログ投稿/記事を保存している場合は、blob/テキスト フィールドを別のテーブルに保存するのが理にかなっている場合があります。何らかの理由でロードされるたびに、ORM は行全体をロードするためです。画像または投稿の URL のみが必要な場合、データベースからバイナリ/テキスト全体を取得することは、最も避けたいことです。それでも、あなたのORMはそれを行います...
はい、一般的に。
例外として、列のサブセットに異なる権限を割り当てる場合があります。
また、これは両側が必要な場合にのみ当てはまると考えてください。
理由の 1 つは、アクセス頻度の高いデータを 1 つのテーブルに配置し、アクセス頻度が非常に低いデータを別のテーブルに配置することです。より高速に実行され、メモリを節約できます。
しかし、そうする前に、腕を強くひねる必要がありました。