2

私は長年リレーショナルデータベースをプログラミングしてきましたが、今では珍しくてトリッキーな問題に遭遇しました。

私は、（ユーザーが）非常に迅速かつ簡単に定義できるエンティティを必要とするアプリケーションを構築しています。これらのエンティティのインスタンスは、作成、更新、削除などが可能です。

私が考えることができる2つのオプションがあります。

オプション1-動的に作成されたテーブル

最初のオプションは、テーブルを動的に生成するエンジンを作成し、それらにデータを挿入することです。ただし、すべてのクエリも動的であるか、少なくとも動的に作成されたストアドプロシージャなどである必要があるため、これは非常に注意が必要です。

オプション2-エンティティ-キー-値パターン

これは私が考えることができる唯一の現実的なオプションであり、5つのテーブル構造があります。

EntityTypes

EntityTypeID int

EntityTypeName nvarchar（50）

エンティティ

EntityID int

EntityTypeID int

FieldTypes

FieldTypeID int

FieldTypeName nvarchar（50）

SQLtype int

FieldValues

EntityID int

FIeldID int

値nvarchar（MAX）

田畑

FieldID int

FieldName nvarchar（50）

FieldTypeID int

「FieldValues」テーブルはデータウェアハウスのファクトテーブルのように機能し、すべての挿入/更新は「Key / Value」テーブル値パラメーターを入力してこれをSPROCに渡すことで機能します（複数の挿入/更新を回避するため）。

すべてのテーブルに高度なインデックスが付けられ、データを取得するために多くの自己結合を実行することになります。

Key / Valueデータベースの悪さについて多くのことを読みましたが、この問題については、それでも最善のようです。

今私の質問！

  • 誰かがこれらの2つのオプション以外の別のアプローチまたはパターンを提案できますか？
  • オプション2は、中規模のデータセット（最大100万行）で実行可能でしょうか？
  • 使用できるオプション2のさらなる最適化はありますか？

どんな方向性やアドバイスも大歓迎です！

4

4 に答える 4

3

個人的には、 MongoDBのような「noSQL」（キー/値）データベースを使用します。

ただし、リレーショナルデータベースを使用する必要がある場合は、オプション2を使用することをお勧めします。この種のモデルの良い例は、Alfrescoデータディクショナリです（Alfrescoはエンタープライズコンテンツ管理システムです）。設計はあなたが説明したものと似ていますが、フィールド値用の複数の列があります（データベースで使用可能なすべての単純なタイプに対して）。それに優れたキャッシュシステム（ Ehcacheなど）を追加すると、正常に機能するはずです。

于 2011-12-22T21:15:20.800 に答える
1

これは問題を探すための解決策かもしれないようです。ドメインをリファクタリングできる可能性はありますか？そうでない場合-まだ希望があります。

  • オプション2のスケーラビリティは、カスタムオブジェクトの幅に大きく依存します。動的に作成できるフィールドの数はいくつですか？各エンティティに100個のフィールドがある場合、100万個のエンティティはドラッグになる可能性があります...効率的なインデックス作成により、パフォーマンスが耐えられるようになる可能性があります。

  • 別のオプションとして、いくつかの文字列フィールド、いくつかのdoubleフィールド、およびいくつかの整数フィールドを持つ1つのデータテーブルを作成できます。たとえば、。を含むテーブルString1, String2, String3, Int1, Int2, Int3。ユーザーオブジェクトを定義し、「CustomObjectName」=>String1などをマップする行を持つ2番目のテーブル。INFORMATION_SCHEMAといくつかの動的SQLを読み取るストアドプロシージャは、スキーマテーブルを読み取り、強く型付けされたレコードセットを返すことができます。

  • さらに別のオプション（最近のバージョンのSQL Serverの場合）は、ID、型名、およびオブジェクトデータを含むXMLドキュメントを含むXMLフィールドを含む行を格納することです。MS Sql Serverでは、これを直接照会でき、スキーマに対して検証することもできます。

于 2011-12-22T21:05:57.963 に答える
1

他の人がNoSQLを提案しているように、私の意見では、スキーマレスデータベースはスキーマのないユースケースに本当に最適であると言います。

説明と思いついたスキーマから、あなたのケースは実際には「スキーマなし」ではなく、「ユーザー定義スキーマ」のように見えます。

実際、思いついたスキーマは、リレーショナルデータベースの内部メタスキーマと非常によく似ています。（リレーショナルデータベースの上にリレーショナルデータベースを構築しているようなものですが、この「メタデータベース」は基本的な操作の少なくとも2倍のオーバーヘッドと複雑さを伴うため、私の経験ではお勧めできません。テーブルは非常に大きくなり、拡張性が低くなり、データのクエリと更新が困難になり、問題のデバッグが困難になります。）

そのようなユースケースでは、おそらくDDL：データ定義言語が必要です。

使用しているSQLデータベースはわかりませんが、ほとんどのSQLデータベース（MySQL、PostgreSQL、MS-SQLなど）は、実際のスキーマを操作できるSQL構文のDDL拡張機能の一部をサポートしています。

私は過去にあなたのようなユースケースでこれを成功させました。スキーマがめったに変更されず、各ユーザーのデータ量が比較的少ない場合に適しています。（大量のスキーマまたは頻繁なスキーマ更新の場合は、スキーマレスまたはその他のタイプのNoSQLデータベースが必要になる場合があります。）

SQLスキーマに適合しない追加のフィールド情報のために、側面にいくつかのテーブルが必要になる場合があります。実際のスキーマから読み戻すのが困難または非効率になる可能性があるため、そこにもいくつかのスキーマ情報を複製することをお勧めします。

フィールド情報テーブルとスキーマのアトミック更新を保証するには、おそらくトランザクションが必要ですが、データベースエンジンではサポートされていない可能性があります。PostgreSQLは少なくともトランザクションスキーマの更新をサポートしています。

セキュリティに関しては注意が必要です。ユーザーが想定外のものを作成、保存、または削除することに自分自身を開放したくないのです。

ユースケースに適している場合は、個別のテーブルだけでなく、個別のデータベースを使用することを検討してください。これらのデータベースは、DDLを使用してオンデマンドで作成および破棄することもできます。これは、各顧客が、顧客間で照会できない、すべきでない、または照会する必要のないデータ収集の所有権を持っている場合に適用できます。（おそらく、これらはまれです。通常、少なくとも顧客全体で分析などが必要ですが、各顧客が、分離され、ホストされたWiki、ショップ、またはある種のCMS / DMSを「所有」している場合があります。）

（コメントで、すでにNoSQLを決定していることがわかりました。完全を期すために、このオプションをここに投稿してください。）

于 2021-09-11T08:48:43.660 に答える
0

個人的には、すべてにEAVを使用するよりも、できるだけ多くの属性を定義するのに時間がかかります。確かにあなたはいくつかの属性を知っています。次に、本当にクライアント固有のものに対してのみEAvが必要です。

しかし、すべてがEAVでなければならない場合は、nosqlデータベースが最適です。または、いくつかのものにはRelationslaデータベースを使用し、残りの部分にはnosqlデータベースを使用できます。

于 2014-10-31T14:50:42.373 に答える