テーブルBと1対1の関係を持つテーブルAがある場合、それらを離しておくことは意味がありますか？または、それらを単一のテーブルに結合しても害はありませんか？これらのシナリオ（2つのテーブルと1つの結合されたテーブル）のいずれかが、通常の形式（1NF、2NF、3NFなど）に関して何か影響を与えますか？
回答:
はい、これがより良いデザインである理由はたくさんあります。
継承/拡張関係がある場合があります。たとえばUser、Administratorテーブルがあり、さらにフィールドがあるテーブルがあります。両方のテーブルにユーザーIDのプライマリキーがあります（したがって1：1の関係があります）が、すべてのユーザーがAdministratorテーブルにレコードを持つわけではありません。ScheduledTaskテーブルやCompletedTaskテーブルなど、ワークフローをサポートしている場合は、同様のものが必要になります。
一般的に使用されるデータ用に軽量のテーブルを作成しUser、あまり必要でない詳細用に大きなテーブルを作成することができますUserDetails。これにより、より多くのレコードを単一のデータページに収めることができるため、パフォーマンスが向上します。
あなたは、例えば、テーブルに異なるアクセス許可をすることができUser、およびUserCredentials
異なるバックアップ戦略が必要な場合、異なるパーティションに2つのテーブルを置くことができます。たとえばTransaction、TransactionArchive
単一のテーブルでサポートできるよりも多くの列が必要になる場合があります。たとえば、インデックスを作成する必要がある大きなテキスト列が多数あり、DBプラットフォームが4Kデータページまたはwhathaveyouに制限されている場合です。
もう1つの理由は、@ john-wuによる優れた答えに加えて、写真のようなBLOBタイプの列がある場合です。
そのBLOB列を別のテーブルに配置したいのは、ユーザーテーブルのクエリが高速であるだけでなく、BLOBを含むテーブルをより安価で低速のストレージ上の別のテーブルスペースに移動し、最もクエリされたデータをより高速なストレージ上のメインテーブルスペース。
1対1の関係は、表Bの関連レコードをオプションにする場合にのみ意味があります。
時々あなたが望むのはバリアントレコードですまたはTagged Unionです。つまり、異なる情報を含む複数のテーブルがありますが、それらはすべて1対1の関係でテーブルAに関連しています。次に、テーブルAのフィールドに基づいて、関連付けるテーブルを選択します
例えば：
type Transaction(The_Type: PaymentType := Cash) is record
Amount: Integer;
case The_Type is
when Cash =>
Discount: boolean;
when Check =>
CheckNumber: Positive;
when Credit =>
CardNumber: String(1..5);
Expiration: String(1..5);
end case;
end record;
ビジネスモデリングでは、ビジネスの観点から論理的に分離されている2つのエンティティAとBは、通常、異なるテーブルにマッピングされます。
たとえば、オブジェクト指向の手段を使用してビジネスモデリングを行う場合、通常、何らかの種類のオブジェクトリレーショナルマッピングが用意されています。オブジェクトモデルから始めて、そこからリレーショナルモデルを派生させることができます。オブジェクトモデルでクラスAとクラスBを作成したとします。クラスAとBは、オブジェクトは1：1の対応関係を持っていますが、単一の責任原則のために分離されたままでなければなりません。オブジェクトモデルでは、これらのクラスは属性を持つ単なるテーブルではなく、メソッドに実装されたいくつかの動作を備えたビジネスオブジェクトを表す場合があります。そして、これらのクラスをリレーショナルモデルに簡単にマッピングすると、1対1の関係を持つ個別のテーブルAとBが得られます。
私の経験では、ビジネスまたはオブジェクト指向のデータモデルを作成する場合、この論理的な分離は、パフォーマンス、個別のセキュリティ、パーティション分割などの「物理的な」理由よりも1：1の関係のほうがはるかに一般的です。