2

私は純粋なリレーショナル デザインが好きですが、データを格納するためのエンティティ/値メソッドが必要になる場合があります。特に、ユーザーが新しいタイプのデータを頻繁に作成する必要がある場合。

一部の商用ソフトウェアでは、EV テーブルを使用するのではなく、標準テーブルを動的に作成するのを見てきました。

明らかに、これはすべてを解決するソリューションではなく、定義できるデータの種類を制限した場合にのみ機能します。ただし、次の利点があります。

  • モデルは明確に定義されています。スキーマを理解するためにスキーマを調査する必要はありません。
  • テーブルはそのタイプのデータのデータのみを保持するため、パフォーマンスが向上します。したがって、明らかに無関係な行をクエリする必要はありません。
  • 同様に、インデックスは、テーブルが定義するデータ型の値のみを保持するため、パフォーマンスが向上します。(つまり、EV モデルでは、インデックスが valueid,entityid の場合 - インデックスを分割しない限り、クエリとは関係のないエンティティの値を検索することになります)。

私にはこれは素晴らしいことのように思えますが、このアイデアを DBA に実行させると、歯を食いしばることになります。これは良い考えですか、落とし穴は何ですか、そして誰かがこれをやろうとしましたか?

4

2 に答える 2

2

まず第一に、アプリケーションはデータベース構造を変更する権限を持っていないため、データベース構造を変更できないようにする必要があります。

2 つ目:優れたデータベース構造をその場で作成するための優れたソリューションを作成するオーバーヘッドは、報われないと思います。

3 つ目: データベースを使用する他のこと (バックアップ、スクリプトの保守、他のアプリケーションなど) が不適切に行われた場合、重大な副作用を引き起こす可能性があります。

于 2009-01-17T12:10:21.243 に答える
1

少し前に、私はオンライン調査アプリケーションを作成しました。データベース スキーマとしてハイブリッド フォームを使用しました。

  • 最初に値をキー/値テーブルに格納します。
  • キーと値のペアが調査ごとにカスタム テーブルに変換されるため、動的な一時テーブルを使用します。
  • INSERT INTO temp_table SELECT ...これらの一時テーブルをいっぱいにすることは、多くの を使用して、単一の重いステートメントで行うことができますLEFT JOIN。

調査には通常、回答を挿入するフェーズと結果を分析するフェーズがあるため、このアプローチはこの特定のアプリケーションには理想的でした。

  • 一時テーブルの作成には時間がかかる場合がありますが、調査が終了した後に一度だけ行う必要がありました。
  • その後の結果テーブルのクエリは非常に高速でした。
  • 一時テーブルが削除された場合や古くなった場合に自動的に再作成されます。このため、バックアップする必要はありませんでした。

だから私のアドバイス：意図された用途が何であるかを考えてください。この例は、このアプリケーションの特定の要件のためにのみ機能しました。主に値の挿入と更新 (OLTP) を行っていますか? それとも、集計クエリ (OLAP) を実行しますか? この質問の答えに従ってスキーマを構築してください。

于 2009-01-17T12:23:37.160 に答える