これまでの場合 特定の属性の検索を計画している場合は、情報を取得するために行ごとの関数を使用する必要があるため、それらを1つの列にシリアル化することはお勧めできません。これは、適切にスケーリングされることはめったにありません。
私はあなたの2番目の選択肢を選びます。属性テーブル内の属性のリスト、独自のテーブル内のオブジェクト、およびオブジェクト属性と呼ばれる多対多の関係テーブルを用意します。
例:
objects:
object_id integer
object_name varchar(20)
primary key (object_id)
attributes:
attr_id integer
attr_name varchar(20)
primary key (attr_id)
object_attributes:
object_id integer references (objects.object_id)
attr_id integer references (attributes.attr_id)
oa_value varchar(20)
primary key (object_id,attr_id)
パフォーマンスに関する懸念は指摘されていますが、私の経験では、複数の列を組み合わせるよりも、列を分割する方が常にコストがかかります。パフォーマンスの問題があることが判明した場合は、パフォーマンス上の理由から3NFを中断することはまったく問題ありません。
その場合、同じ方法で保存しますが、シリアル化された生データを含む列もあります。挿入/更新トリガーを使用して列データと結合データの同期を維持する場合、問題は発生しません。しかし、実際の問題が表面化するまで、それについて心配する必要はありません。
これらのトリガーを使用することで、のみに必要な作業を最小限に抑えることができます。 データが変更されたとき。サブ列情報を抽出しようとすると、すべてで不要な作業を行うことになります。 選択します。