asp.netアプリケーションで新しい列を追加する

Question

新しい小さなプロジェクトでこの質問に直面しています： 構築するシステムによって、ユーザーはシステム内のテーブルに新しい列を追加できるようになります。データを維持するために、私はこれを実装する2つの方法があると思います： 1） "columnName" "columnValue" "datatype"などを含むいくつかのテーブルを作成して、カラム定義を保存し、別のテーブル "XXCoumn" （ユーザーが入力した）列の値、および列データを照会または更新するストア・プロシージャーを示します。 2）ユーザーが新しい列を入力したときにテーブルスキーマに列を作成し、次にテーブルデータの更新を通常と同じようにします。

どのようにお考えですか？または任意の新しい提案？

追加情報：データの量が少なく、レポートを作成する必要があります。

Answer 1

適切な推奨事項であれば、要件をよく理解する必要がありますが、ここで言及したオプションに関するコメントと追加の考えがあります。

1）エンティティ属性値（EAV）デザイン：これは、列名、型、および値の列を持つ表がある場所を記述するオプションです。このオプションには、無制限の新しい列を簡単に収容できるという利点がありますが、意味のあるデータを取り出すときに苦労することがわかりました。たとえば、{Color、varchar} {Red、Green、Blue}、{Size、varchar} {Small、Medium、Large}のEAVテーブルに行があるとします。

SELECT * 
FROM ITEMS 
WHERE COLOR = 'Green' AND SIZE = 'Small' 

：色やサイズのための項目のテーブルの上に実際の列を持つ

SELECT * 
FROM ITEMS 
WHERE ITEMID IN (SELECT ITEMID 
       FROM ITEM_ATTRIBUTES ATT INNER JOIN ITEM_VALUES VLS 
        ON ATT.AttributeID = VLS.AttributeID 
       WHERE ATT.ColumnName = 'Color' AND VLS.Value = 'Green') 
    AND ITEMID IN (SELECT ITEMID 
       FROM ITEM_ATTRIBUTES ATT INNER JOIN ITEM_VALUES VLS 
        ON ATT.AttributeID = VLS.AttributeID 
       WHERE ATT.ColumnName = 'Size' AND VLS.Value = 'Small') 

コントラストこの：あなたはすべての小さな緑のアイテムを検索したい場合は、この（もちろん、テストされていないSQL）のようなものを必要とします

さらに、データの整合性を維持するのは難しいでしょう（これはこのアプリケーションにとって重要です（ほとんどの場合、特に指示があっても重要です）。上記の例では、「色」を青、緑、赤に限定する必要がある場合は、余分なロジックを実装する必要があります。特定の色だけ特定のサイズに来る場合にも、あなたも、より多くのロジックを実装する必要があります（例 - ブルーのアイテムは、中小でのみ利用可能です）

2）ユーザー定義列：ちょうどユーザーに能力を与えますテーブルに列を追加すると、データの取得が簡単になりますが、データの整合性の問題はすべて残ります。また、あなたのアプリは通常、未知の列を処理するために余分なロジックを必要とします。

3）既存のカスタム列：私はCRMなど、ユーザー定義のために既に十数個以上の列を提供するいくつかのアプリケーションを扱っています。基本的に、デザイナーは "Text1"、 "Text2"、 "Text3"、 "Number1"、 "Number2"などの列に入れます。ユーザーはこれらの列のヘッダーと説明情報を提供します。表示目的。このモデルには、簡単なデータ検索の利点と、事前定義されたDBスキーマがあり、アプリケーションロジックを簡素化することができます。しかし、データの完全性の問題は残っています。もう1つの明らかな欠点は、この種のソリューションでは避けようとしている、あらかじめ定義された列が不足することです。

ほとんどの設計上の問題と同様に、各ソリューションにはトレードオフがあります。私の経験では、多くのユーザー/クライアントは、これらのようなソリューションを望んでいると言いますが、実際には、ニーズに合わせて成長できないアプリにトラップされないようにしています。私は、実際にはこのようなデザインが必要な場所はほとんどないことを発見しました。私はほとんどいつでも、データベースデザイナーの役割を果たすことなく、クライアントの拡大の欲求に対応するデザインを作成することができます。

Answer 2

これが一元的にホストされている場合は、ユーザー入力データでデータベースのスキーマを変更することを許可しないでください（新しいテーブルの作成を促す）。

むしろ、データの可変フィールド名やより一般的なテーブル構造を格納するために、SQLのXMLフィールドを使用してみるといいでしょう。このテクニックは、狂った量のデータを話していない場合にはうまくいきます。 。

Answer 3

ソリューションを横向きに見ている可能性はありますか？マッピングテーブル（あなたの＃1のようなもの）が必要なようです。あなたはテーブルを持っています。たとえば、 "objects"は "properties"というテーブルで、カラムを保持しているテーブルと値を保持するテーブルを保持しているので、object_id、property_id、valueだけを持っています。

Entity-attribute-valueモデルを見て、私が言ったよりスマートな方法を考えてみましょう。

Answer 4

本当に

「を構築されるシステムは...ユーザーがシステムのテーブルに新しい列を追加することができます」 - それは、ユーザーの話ですか？あなたはすでに解決策について私に思いついたように思えます。

ユーザーがスキーマを拡張できるようにするかどうかは、かなりコンテキストに依存します。私は管理者のように、限られた使用方法ではほとんど問題がないだろう。しかし、それはMySpaceタイプの方法ではひどく悪い考えです。私はあなたの状況がこれらの2つの極端な状況の間にあると考えています。

スキーマを拡張すると、索引などを追加することができるため、より効率的な問合せにつながりますが、ユーザーにはいくつかのリレーショナル・ルールが公開されます。また、拡張機能は（おそらく）テーブル全体をロックし、同時に編集する必要があります。