フィールドにデータ構造を埋め込むことは単純なケースでは機能しますが、リレーショナルデータベースを利用できなくなります。リレーショナルデータベースは、データを検索、更新、削除、保護するように設計されています。独自のwad-o-data（配列、JSON、xmlなど）を含む埋め込みフィールドを使用すると、これを行うためのすべてのコードを自分で作成することになります。
埋め込みフィールドの方が適している場合もありますが、この質問では、例として、関連するテーブルアプローチの利点を強調するケースを使用します。
ブログのユーザーと投稿の例を想像してみてください。
埋め込み投稿ソリューションの場合、次のようなテーブルがあります（擬似コード-これらはおそらく有効なddlではありません）：
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
関連するテーブルを使用すると、次のようなことができます
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
オブジェクトリレーショナルマッピング（ORM）ツール ：埋め込み投稿を使用すると、ユーザーに投稿を追加したり、既存の投稿をナビゲートしたり、検証したり、削除したりするためのコードを手動で記述します。別のテーブルデザインを使用すると、ActiveRecord（または任意のオブジェクトリレーショナルシステム）を活用できます。コードをはるかに単純に保つためのツールを使用しています。
柔軟性 ：投稿に日付フィールドを追加するとします。埋め込みフィールドでそれを行うことができますが、配列を解析し、フィールドを検証し、既存の埋め込み投稿を更新するなどのコードを作成する必要があります。別のテーブルを使用すると、これははるかに簡単です。さらに、すべての投稿を承認するエディターをシステムに追加するとします。リレーショナルの例では、これは簡単です。 ActiveRecordで「Bob」によって編集されたすべての投稿を検索する例として、次のものが必要です。
Editor.where(name: 'Bob').posts
埋め込み側の場合、データベース内のすべてのユーザーをウォークスルーし、すべての投稿を解析して、エディターフィールドで「Bob」を探すコードを作成する必要があります。
パフォーマンス ：10,000人のユーザーがいて、それぞれ平均100件の投稿があるとします。ここで、特定の日に行われたすべての投稿を検索する必要があります。埋め込みフィールドを使用して、すべてのレコードをループし、すべての投稿の配列全体を解析し、日付を抽出して、必要な日付を再確認する必要があります。これにより、CPUとディスクi/0の両方が噛み砕かれます。データベースの場合、すべてのユーザーからのすべての投稿を解析することなく、日付フィールドに簡単にインデックスを付けて、必要な正確なレコードを引き出すことができます。
標準 ：ベンダー固有のデータ構造を使用するということは、アプリケーションを別のデータベースに移動するのが面倒な場合があることを意味します。 Postgresには豊富なデータ型のセットがあるように見えますが、それらはMySQL、Oracle、SQL Serverなどと同じではありません。標準のデータ型を使用すると、バックエンドを交換する時間がはるかに簡単になります。
これらは私が上から見た主な問題です。私はこの間違いを犯して代金を支払ったので、特別な理由がない限り、別のテーブルを使用します。