1

多くのプロパティを持つオブジェクトを格納するスキーマを設計する必要がありますが、共通点はほとんどありません。

ここでいくつかの解決策を見つけましたが、最善の方法についてはまだ確信が持てません。私はそれを行う4つの方法を見ます:

  1. 多くのフィールドを持つ 1 つのテーブル : これにより、多くのNULL値が発生する可能性があり、いくつかのプロパティを追加したり、いくつかのデータ型を変更したりする必要がある場合に苦労します。
  2. プロパティごとに新しいテーブルを作成します。これにより、列の追加と更新が簡単になり、検索機能が保持されますが、それぞれSELECTが多くのJOIN.
  3. タグ、数量、間隔など、プロパティのタイプごとにテーブルを作成します。その場合、浮動小数点数、小数、整数などを区別する必要があるかどうかわかりません。
  4. プロパティ名とデータ型を格納する抽象テーブルを作成します（ここでは観察パターンと呼びます）。

これらのソリューションから選択するには、どの基準に従う必要がありますか? また、どの質問に答える必要がありますか?

ありがとう

4

2 に答える 2

1

これは、使用している ORM テクノロジとオブジェクトのシリアル化機能に依存していると言えます。

一般的に、私は抽象化と柔軟性を好みます。

于 2011-04-23T19:51:04.080 に答える
0

プロパティで何をする必要があるかによって異なります。プロパティが間接的な関心のみである場合、4 は非常に柔軟でコンパクトなソリューションです。間接的な利益とはどういう意味ですか? プロパティの情報を取得して表示する必要がある場合、これは間接的です。プロパティを使用して計算または詳細な操作を行う必要がある場合、これはより直接的です。つまり、プロパティで使用する可能性が高い唯一のメソッドが ".ToString()" である場合は、4 で済ませることができます。このスキーマには、データベースを変更せずに新しいプロパティ タイプを追加できるという大きな利点があります。これは、プロパティ タイプ テーブルへの新しい行の挿入にすぎないためです。

一方、さまざまなプロパティ タイプをデータ タイプに応じた方法で操作する必要がある場合、さまざまなタイプのプロパティを 1 つのフィールドに格納するのは面倒です。この場合は 3. を実行できますが、特定の型の値を取得するためにどのテーブルに移動するかを知る必要があるため、これも問題です。これは克服できない問題ではありませんが、エレガントでもありません。

3. の代わりに、単一のプロパティ テーブルに複数の列があり、データ型ごとに 1 つずつ、できれば別の列 (おそらく計算列) が "ToString" として機能する、一種のハイブリッド アプローチを試すことができます。このようにして、間接的な使用は単純で予測可能な場所に行くことができ、より複雑なアプリケーションのみが特定のプロパティ タイプのどの列に移動するかを心配する必要があります。

于 2011-04-23T21:07:23.040 に答える