0、背景

テーブルを設計して完成させるとき、ビジネスの変化や新しい機能要件が増えるにつれて、いくつかの新しい関数を完成させるためにいくつかのフィールドを追加する必要があることがよくあります。現時点では、それについて考えない場合は、次のフィールドを直接追加できます。コース。
しかし、テーブル内のすべてのデータにデータのごく一部しか含まれていないか、このフィールドが値に含まれているか、他のビジネスシナリオではフィールドが空であるか、テーブル内の各データにこのフィールドが必要かどうかを真剣に検討しましたか？？してください
自問してみてください。非常に一般的なアプリケーションケース
を考えてみましょう。eコマースシステムでは、商品を入力する必要があります。靴などの一部の商品にはサイズとサイズがあり、食品などの一部の商品には仕様、貯蔵寿命、商品テーブルのデザインがあります。。共通フィールドのみを含めることができ、製品データは
特定のフィールドに分割されているため、製品テーブルに配置するのには適していません。このシナリオでは、テーブルの拡張フィールドを考慮する必要があります。一般的なテーブル拡張フィールドには、集中型と分散型の2つのスキームがあります。

1.集中テーブル拡張フィールドスキーム

テーブルのDDLスクリプトは次のとおりです。

CREATE TABLE `sys_tab_ext_prop` (
  `id` int(8) NOT NULL COMMENT '主键',
  `table_name` varchar(255) DEFAULT NULL COMMENT '表名',
  `data_id` varchar(255) DEFAULT NULL COMMENT '表中数据Id',
  `property_name` varchar(255) DEFAULT NULL COMMENT '属性名',
  `property_value` varchar(255) DEFAULT NULL COMMENT '属性值',
  `property_remark` varchar(255) DEFAULT NULL COMMENT '属性备注',
  `created_time` datetime NOT NULL COMMENT '创建时间',
  `updated_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `data_id` (`data_id`) USING BTREE COMMENT '外键索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='表扩展属性';

テーブルの構造は次のとおりです。

利点：

1.各ビジネステーブルは、各テーブルの拡張フィールドに注意を払わなくなりました。テーブル拡張コンポーネントは、統合データストレージ、パブリックAPIインターフェイス、およびビジネステーブルからの分離を提供します
。2 。に基づくビジネステーブルの条件付き検索をサポートします。拡張フィールド、もう1つの接続テーブルクエリ、パフォーマンスは単一のテーブルと大差ありません

短所：

1.すべてのテーブル拡張フィールドがこの拡張フィールドテーブルに格納されるため、データ量の増加率が加速され、ボトルネックになる可能性があります。

2.分散テーブル拡張フィールドスキーム

2.1複数の拡張フィールド

テーブルの構造は次のとおりです。

分散テーブル拡張フィールドスキーム。テーブルの拡張フィールドをビジネステーブルと組み合わせて、pro1、pro2、pro3などの特定の数の拡張フィールドを事前に設計します。

利点：

1.拡張フィールドと基本ビジネスフィールドが同じテーブルにあり、クエリのパフォーマンスが向上します。必要に応じてインデックスを作成できます。

短所：

1.ビジネステーブルは、各テーブルの拡張フィールドに注意を払う必要があり、各ビジネステーブルは、対応するコード開発作業を完了する必要があります。

2.拡張フィールドの数を決定するのは非常に簡単ではありません。事前に特定の数の拡張フィールドを設計しておくと、後で動的に拡張フィールドの数を増やすことができます。

3.ビジネス開発者は、各拡張フィールドに格納されているコンテンツタイプを詳細に記録する必要があり、拡張フィールドを混在させることはできません。

2.2Json拡張フィールド

テーブルの構造は次のとおりです。

分散テーブル拡張フィールドスキーム（Json）、テーブルの拡張フィールド、およびビジネステーブルがまとめられ、extフィールド全体にすべての拡張フィールドの内容が格納されます。

利点：

1.拡張フィールドは、基本的なビジネスフィールドと同じテーブルにあり、データの読み取りと書き込みが容易になります。

2.データベースのテーブル構造を変更せずに、後で拡張フィールドを追加する方が便利です。

短所：

1.拡張フィールドは、特定の拡張フィールドによる検索をサポートしていません。検索の問題を解決したい場合は、テーブルデータをElasticSearchにロードし、json形式の拡張フィールドを1つのフィールドに分割し
て、キーワードとして設定できます。 ElasticSearch Typeでは、単語のセグメント化は不要であるため、検索要件を達成できます。'％keyword％'（パフォーマンスの低下）のようなまぐれはここにありません。テーブルが大きく、
ElasticSearchと同期する必要がある場合は、別のドキュメントを参照してください：迂回を避けるための大きなテーブルの技術実装計画の同期。

テーブル拡張フィールドの2つの実装スキームに関する研究

0、背景

1.集中テーブル拡張フィールドスキーム

利点：

短所：

2.分散テーブル拡張フィールドスキーム

2.1複数の拡張フィールド

利点：

短所：

2.2Json拡張フィールド

利点：

短所：

おすすめ