2

少し凝ったことかもしれませんが、リレーショナルデータベース（nosqlではない）に任意の種類のオブジェクトを最適な方法で格納するためのパターンや何かがありますか？

たとえば、最適な方法はありません。

class Person{
    string FirstName {get;set;}
    string LastName {get;set;}
} 

class Product{
    string Name {get;set;}
    decimal Price {get;set;}
}

およびデータベース内：

CREATE TABLE Data
   (Id int PRIMARY KEY, 
    TypeName nvarchar(50), 
    PropertyName nvarchar(50), 
    PropertyValue binary)

次に、レコードは次のようにデータベースに保存されます。

1    Person    FirstName   Jalal

2    Person    LastName    A.R

3    Product   Name        Apple

4    Product   Price       2
4

4 に答える 4

3

あなたが説明しているのは、本質的にEntity-Attribute-Valueテーブルです。

これは、潜在的な属性の数が多く、潜在的な値の数が少ない場合に適切に使用されます。このようなユース ケースの例として、医療データ (症状) があります。この場合、患者が持つ潜在的な症状の数は多くても、実際の症状の数は少なくなります。

不適切に使用すると、これはInner Platform Effectの典型的な例です。

于 2012-02-28T20:07:53.503 に答える
2

オブジェクトを XML にシリアル化し、それをデータベースに格納できます。SQL Server には、コンテンツに対してクエリを実行できる特殊な XML 型があります。

これは最適なソリューションではありませんが、必要なことは実行できます。

于 2012-02-28T20:08:37.133 に答える
0

なぜこれを最適とは言えないのかわかりません。人を探す場合は、文字列値に対してテーブル スキャン/インデックス ルックアップを行い、主キーでフィルター処理します。

ORMの方がはるかに優れています-nHibernateまたはEntity Framework（EF）は、各クラスをテーブルにマップし、主キーなどを自動生成し、オブジェクトを子オブジェクトなどとして表現できます.

EF は最初にコードを実行することもできます。つまり、クラスを作成するだけで、データベースが作成され、それらがすべて自動的にマップされます (nHibernate もおそらく同様に機能しますが、製品もわかりません)。

于 2012-02-28T20:17:42.053 に答える
0

あなたが説明したことはリレーショナル アプローチではないため、リレーショナル データベースを使用する理由がわかりません。すべてのオブジェクトを 1 つの大きなテーブルにまとめています。テーブル間のリレーションシップを定義したり、リレーショナル操作 (「今月リンゴを購入したすべての顧客を検索する」など) を実行したりする機能が完全に失われます。

于 2012-02-28T20:23:51.233 に答える