テーブルを使用してGadgetData、ガジェットのプロパティをアプリケーションに格納します。ガジェットは基本的に、高さ、幅、色、タイプなどの一般的なプロパティの 80% を持つカスタム コントロールのようなものです。ガジェット タイプごとに固有のプロパティ セットがあります。このデータはすべてデータベースに保存する必要があります。現在、共通のプロパティのみを保存しています。列が動的であるこの種のデータを格納するには、どの設計アプローチを使用する必要がありますか。
(注: ガジェットの種類の数は 100 を超える可能性もあります)
オプション 3 は非常に正規化されたオプションですが、複数のタイプにまたがってクエリを実行する必要がある場合は、戻ってきて噛み付きますSELECT。新しいタイプが追加されると、すべてに別の結合が必要になります。メンテナンスの悪夢。
オプション 2 (スパース テーブル) には多くの NULL 値が含まれ、余分なスペースが必要になります。将来別のタイプが追加された場合は、テーブル定義も更新する必要があります。悪くはないけどまだ痛い。
本番環境ではオプション 1 を使用します ( のxml代わりに型を使用text)。これにより、共通の型から派生した任意の型をシリアル化して、共通のプロパティを抽出し、一意のプロパティをXmlProperties列に残すことができます。これは、アプリケーションまたはデータベース (ストアド プロシージャなど) で実行できます。
すべてのタイプのガジェットに、1 つのテーブルに保存できる多くの共通の必須プロパティといくつかのオプション プロパティしかない場合は、最初のアプローチを使用することをお勧めします。したがって、最良のリレーショナル スキーマを使用し、XML を簡単に使用できます。また、XML 列をそれにリンクする XML スキーマ コレクションを使用することを忘れないでください。完全なインデックス作成機能と XQuery 機能を利用できます。
ガジェット タイプの説明が大きく異なり、5 つ以上の異なるプロパティ セットの中で共通の列が 1 ～ 3 つしかない場合は、3 番目の方法を使用します。
しかし、100 種類以上のガジェットの状況に関しては、最初のアプローチを使用します。優れたパフォーマンスと、サポートとさらなる開発の容易さでサポートされる柔軟性があります。
オプション:
ノート：
データベースを「リレーショナル」に保ちたいが、ORM ツールを使用することを恐れない場合は、それを使用します。この場合、(ほぼ) 必要に応じてデータを保存できますが、データを正しくマッピングする限り、データを適切に処理できます。見る：
SQL のみのソリューションが必要な場合は、RDBMS によっては、おそらく XML 列を使用して、ガジェットの種類に固有のすべてのデータを格納します。検証を行い、新しい属性で簡単に拡張できます。次に、すべてを 1 つのテーブルにまとめて、すべての一般的な属性をすばやく検索し、1 つのガジェットのタイプ属性も非常に簡単に検索できます。
「ガジェット」の違いによっては、オプション 2 が好きではありません。多くの null が浮かんでいるため、あるガジェットでは必須であるが別のガジェットでは使用されていない列があると、状況が悪化する可能性があります。
毎回データベースを変更する必要があるため、ガジェットの数が頻繁に変更されない場合は、オプション 3 のみを使用します。
言及されていないオプションは、ガジェットの一意の値を保持する子テーブルを使用してガジェットを格納することです。ただし、これには、ガジェットの詳細を返すためのかなりの作業や、複数のデータベース呼び出しが必要になります。
テキストの代わりに SQL サーバーの XML 型を使用することを除いて、オプション 1 を残して、ストアド プロシージャ内で XQuery を使用できます。