データベース設計で1対1の関係を使用する必要があるときは、

Question

データベース設計では、1対1の関係をいつ使用する必要がありますか？私の意見では、2つのテーブルが1対1の関係にある場合、それらを1つのテーブルに結合することができます。これは本当ですか？

Answer 1

1. 垂直パーティショニング - しばしば対まれに照会されている別々の列を。

2. alter tableが「高価」である場合、運用システムに列を追加する。

3. Super-type/subtypeパターン。

4. テーブル結合の恩恵を受ける垂直パーティショニング - オプティマイザを提供する は、I/Oとキャッシュを減らすためにこれをサポートします。 4と同様、しかし6NFにダウン -

5. Anchor modeling。

Answer 2

一般的です。

特権を列のサブセットに異なる方法で割り当てる場合は例外です。

また、両側が必要な場合にのみこれが当てはまると考えてください。

Answer 3

頻繁にアクセスされるデータを1つのテーブルに格納し、他のテーブルのデータにアクセスすることはほとんどありません。それはより速く実行され、いくつかのメモリを節約します。

しかし、私はそれをする前に私の腕をひねってしまわなければならないでしょう。

Answer 4

時にはテーブルロックに便利です。データベースに列を追加すると、テーブル全体が完全に書き換えられるまでロックされます。これは、データベースに100k行がある場合にはほとんど影響を与えません。しかし、100Mの行または1Bの行がある場合、それはまったく別の話です...

余計なスペースを取る不都合な行を避けることも有効です。 MVCCを使用していて、一部の列が定期的に上書きされている場合は、別のテーブルに配置することが時折意味があります。間違いなく、自動吸引はついに始まるが、ハードドライブ作業を惜しまないために、テキスト、varchar（n）でいっぱいの行全体、および他に何を知っているのか分からないいくつかのintフィールドが別のテーブルにある。

最後に、ORMのselect *の乱用が考えられます。たとえば、画像やブログ記事/記事を保存している場合は、BLOB /テキストフィールドを別のテーブルに保存するのが理にかなっています。理由やその他の理由でロードされるたびに、ORMは行全体をロードするためです。画像や投稿のURLだけが必要なときは、最後にデータベースからバイナリ/テキスト全体を取り出すことが必要です。まだあなたのORMは、まさにそれを行います... I/Oおよびキャッシュ要件削減する大規模なテーブルのための