DB設計の質問：1対1のリレーションテーブルをいつ使用することにしますか？
私がこれを目にする場所の1つは、たとえば、UserテーブルとUserProfileテーブルがある場合、すべての列をUserテーブルに配置するのではなく、それらを分割することです。
技術的には、すべての列の関係は1対1であるため、すべての列を1つのテーブルに配置できます。
UserProfileテーブルの場合、時間の経過とともにテーブルを変更して列を追加する必要があると誰かが言ったことは知っていますが、これがテーブルを分割する強力な理由ではないと思います。
したがって、UserテーブルとUserProfileテーブルを設計する場合は、1つのテーブルでそれを行う方がよいでしょうか。
1対1の関係を使用したのは、複数のオブジェクトに多形的に属したい場合のみです。
たとえば、アドレスのように。ユーザーには1つの住所があり、企業には1つの住所があり、注目のレストランには1つの住所があります。すべてのインスタンスは同じテーブルで処理され、それを管理する同じコードを持っています。他の場所で再利用できるように、データモデルをリファクタリングするようなものと考えてください。
ビジネスオブジェクトをどのように設計するかを考えてください。50個のプロパティを持つUserオブジェクトを作成しますか、それともいくつかの詳細プロパティを持つUserオブジェクトを作成し、次にプロファイルの他のデータを含むProfileオブジェクトを作成しますか？
テーブル内のデータが関連しているが、同じ目的で存在しない場合は、1対1を使用する必要があります。（おそらくより良い言葉で言うことができます）
また、物事を見つけやすくすることもできます。75列のテーブルを調べなければならないことほど嫌いなことは多くありません。
古典的な理由は、null 許容列を避けることです。
列に NULL 値があると、明確な (保守可能な) SQL を記述することが難しくなる可能性があります。@Ovidはこれについてここに書いており、Chris Dateの作品を参考にしています。
UserProfileテーブルのフィールドが、userテーブルのすべてのレコード数に必要なわけではない場合のみ。たとえば、3,000,000人のユーザーがいて、そのうち3,000人だけがUserProfilesを持っている場合、それらを分割するのが理にかなっている場合があります（null列がたくさんあるのを避けるため）。
データベースの速度が向上し、ストレージのコストが安くなっている今日ですが、この理由でデータベースを分割してもそれほど大きな違いはありません...
これは、このスレッドで今日ポップアップした別の質問からの直接のコピーアンドペーストですが、ここでも役立つと感じています。 データベースを1：1の関係で使用することが理にかなっている時期はありますか？
私は主にいくつかの理由でそれらを使用します。1つは、データの変化率の大幅な変化です。一部のテーブルには、以前のバージョンのレコードを追跡する監査証跡がある場合があります。10列のうち5列の以前のバージョンのみを追跡する場合は、監査証跡メカニズムを備えた別のテーブルに5つの列を分割する方が効率的です。また、書き込み専用のレコード（会計アプリなど）がある場合もあります。金額やアカウントを変更することはできません。間違えた場合は、対応するレコードを作成して、誤ったレコードを調整してから、修正エントリを作成する必要があります。テーブルに制約があり、更新または削除できないという事実を強制していますが、そのオブジェクトには順応性のある属性がいくつかある可能性があります。それらは、変更の制限なしに別のテーブルに保持されます。私がこれを行う別の時間は、医療記録アプリケーションです。サインオフすると変更できない訪問に関連するデータと、サインオフ後に変更できる訪問に関連するデータがあります。その場合、データを分割し、ロックされたテーブルにトリガーを設定して、サインオフ時にロックされたテーブルの更新を拒否しますが、医師がサインオフしていないデータの更新を許可します。
別のポスターは、1：1が正規化されていないことについてコメントしましたが、状況によっては、特にサブタイピングについては同意しません。従業員テーブルがあり、主キーがそのSSNであるとします（これは例です。これが別のスレッドに適したキーであるかどうかについての議論を保存しましょう）。従業員は、一時的または永続的など、さまざまなタイプにすることができます。永続的である場合は、オフィスの電話番号など、入力するフィールドがさらにあります。タイプ='永続的'の場合にのみnullにしないでください。第3正規形データベースでは、列はキー、つまり従業員のみに依存する必要がありますが、実際には従業員とタイプに依存するため、1：1の関係は完全に正常であり、この場合は望ましいです。また、通常は入力される10個の列がある場合、過度にスパースなテーブルを防ぎます。
最近、ほとんどのデータを含む1つのテーブルと、多数のオプションデータを含む別のテーブルがあるテーブルを見ました。
2番目のテーブルには3分の1の行がありましたが、列の数は3倍でした。
これは数年前に行われたもので、列に多くのnull（つまり、空のスペース）を避けます。
しかし、あなたが今これをしているなら、私は気にしないように誘惑するでしょう。空きスペースと一緒に暮らす。アプリケーション開発にかかる煩わしさは、それだけの価値はなく、スペースは開発時間よりも安価です。
これは十分に対処されていますが、私には明らかではなく、明示的に述べられていないことを明確にするために簡単なメモを追加します. 1 対 1 の関係は、テーブル A の各レコードに対して、テーブル B に 1 つの対応するレコードがあることを意味しません。代わりに、テーブル A の各レコードに対して、テーブル B に 0 または 1 つの対応するレコードがあることを意味します。
Shane D. などは、この事実を利用するシナリオについて説明しています。
シェーン D には、非常に有効な理由があると思います。約40列のテーブルで同じ状況に遭遇したので、これらの列のデータはcsvを介してアップロードされ、レポート目的と、頻繁に更新されるこれらのファイルを処理するための一連の列にのみ使用されます.
したがって、解決策として1つのテーブルを維持するとします。そのテーブルで頻繁に更新を実行し、50 列のうち 5 列のみを更新します。すべての更新が行の割り当てを乱し、行チェーンの可能性が高いと感じているため、行チェーンを回避するために、データ ベースを分離するアプローチに従いました。 DML アクティビティについて。
より良い解決策があれば教えてください