2009-05-26 20 views
2

テーブルGadgetDataを使用して、アプリケーションにガジェットのプロパティを格納します。ガジェットは基本的に、高さ、幅、色、タイプなどのプロパティの80%を持つカスタムコントロールの一種です。ガジェットタイプごとに固有のプロパティがいくつかあります。このデータはすべてデータベースに格納する必要があります。現在、共通のプロパティのみを格納しています。この種類のデータを列が動的な場所に格納するには、どのような設計アプローチを使用しますか。SQL Server動的列問題

  1. Columnsとして共通のプロパティを持つテーブルを作成し、Text型の余分な列を追加して、各ガジェットタイプのすべての一意のプロパティをXML形式で保存します。
  2. すべてのガジェットタイプに可能なすべての列を含む表を作成します。
  3. ガジェットのタイプごとに別々のテーブルを作成します。
  4. 他にもお勧めの方法はありますか?

(注:ガジェットの種類の数が偶数100とを超えて成長できた)

答えて

3

オプション3は非常に正規化されたオプションですが、複数のタイプにまたがってクエリを実行する必要がある場合には、あなたが戻ってくるでしょう。SELECTは、新しいタイプが追加されると、メンテナンスの悪夢。

オプション2(疎テーブル)がNULL値をたくさん持っていると、余分なスペースを取るでしょう。将来、別のタイプが追加されると、テーブル定義も更新する必要があります。あまりにも悪くないが、まだ痛い。

Iは、(xmlタイプの代わりtextを用いて)生産でオプション1を使用します。私の共通タイプから派生したタイプをシリアル化し、共通プロパティを抽出し、ユニークなものをXmlPropertiesカラムに残すことができます。これは、アプリケーションまたはデータベース(ストアドプロシージャなど)で行うことができます。

0

私はオプション2を好きではないだろう「ガジェット」がどのように異なるに応じて漂っヌルがたくさんあるだろう1つのガジェットには必須の列があっても、別のガジェットには使用されていない列があると悪くなる可能性があります。

毎回データベースを変更する必要があるため、ガジェットの数が頻繁に変更されない場合は、オプション3に進みます。

説明されていないオプションは、ガジェットに固有の値を保持する子テーブルを持つガジェットを格納することです。しかし、これにはガジェットの詳細や複数のデータベース呼び出しを返すためにかなりの労力が必要です。

オプション1を残して、テキストの代わりにSQLサーバーXMLタイプを使用する以外は、ストアードプロシージャ内でXQueryを使用できます。

1

あなたのオプション:

  1. 良い1。スキーマなどを強制することもできます
  2. これらの列をNULLにすることはできません。したがって、データの整合性が失われます。
  3. 複数のガジェットタイプの検索を許可しない限り、十分ですがオプションあなたはその後、私は1つを使用することになり、「リレーショナル」データベースを維持しますが、ORMツールを使用することを恐れていないしたい場合

    :1、私は

ノートORMを使用することになり

  • 優れています。私はあなたが望むように(ほぼ)データを格納することができますが、それらを正しくマップする限り、適切に処理する必要があります。 を参照してください:

    あなたはSQLのみのソリューションが必要な場合は、お使いのRDBMSに応じて、私はおそらくに固有のすべてのデータを保存するためにXML列を使用しますガジェットタイプ:検証ができ、新しい属性で簡単に拡張できます。 1つのテーブルにすべての共通属性をすばやく検索し、1つのガジェットのタイプ属性も簡単に検索できます。

  • 1

    すべてのタイプのガジェットには、多くの一般的な必須プロパティが1つのテーブルそしていくつかのオプションのプロパティーを使用すると、最初のアプローチを使用したほうがよいでしょう。したがって、リレーショナルスキーマを最大限に活用し、XMLで生活を楽にします。 XML列をリンクするXMLスキーマコレクションを使用することを忘れないでください。完全なインデックス作成機能とXQuery機能があります。

    ガジェットタイプがの場合は、の記述が異なり、5つ以上の異なるプロパティセットのうちの1〜3つの共通の列しかない場合は、3番目のアプローチを使用してください。


    しかし、私は第一のアプローチを使用したいガジェットの100+種類の状況について:それは良いパフォーマンスとサポートし、さらに開発のしやすさとサポートの柔軟性を持っています。