2

field1..field10 の 3 つの 10 フィールドを含むフォームがあるとします。おそらく 10 個のデータベース列を使用して、フォーム データを 1 つ以上のデータベース テーブルに格納します。

数か月後、さらに 3 つのフィールドを追加したいとします。将来的には、要件の変更に基づいて、このフォームからフィールドを追加/削除する可能性があります。フォーム フィールドごとにデータベース列がある場合、フォームを変更するたびにデータベースに対応する変更を加える必要があります。これはメンテナンスの頭痛の種のようです。もっと洗練された方法があるはずです。

私の質問は、UI と疎結合されたデータ モデルをどのように設計すればよいかということです。具体的なユースケースは、ユーザーによる拡張/カスタマイズが可能な CRM システムです。

4

4 に答える 4

2

フィールドを別のテーブルに抽象化して、フォームテーブルに対して多対多になるようにすることができます。

形

ID
名
など

分野

ID
ラベル
値

FormField

FormID
FieldID

于 2008-08-28T14:44:26.230 に答える
1

これを行う本当に正当な理由がない限り、これは一般的に悪い考えです。データベースの最適化とスケーリングが非常に困難になります。

絶対にそうしなければならない場合、Travisの提案は小さなテーブルには問題ありませんが、実際にはそれほどうまくスケーリングすることはできません.

于 2008-09-02T12:09:06.970 に答える
0

私がAIMS（www.totalaims.com）のQuest Computingで働いていたとき、私のチームはこれに対する解決策を思いつきました。要約すると、管理者がメタデータを追加し、その結果、特定のテーブルのデータベースにフィールドを追加できるようにするメンテナンス画面を追加しました。フィールドは、独自のメンテナンス画面と検索画面にも自動的に追加されました。これはOpenACSの上に構築されました。詳細については、www.openacs.orgを参照してください。「flexbase」または「dynfields」を検索するか、www.project-open.org / doc /intranet-dynfield/を参照してください。これは非常にうまく機能しました。主な欠点は主な利点の副作用です。つまり、フィールドの追加は非DBAによって行われる可能性があり、その結果、パフォーマンスが簡単に低下する可能性があります。

于 2008-12-31T14:32:39.973 に答える
0

過去に、データベースの XML 列を使用して追加のフィールドを格納したことがあります。私は通常、XML 列に大きなプロパティ バッグを用意し、XSD を使用して、更新または挿入の際に検証を実施します。データを取得するとき、XSL またはオブジェクト モデルに、要素が表示されるかどうか、適用する追加の書式設定、およびプロパティ ノードのデータの種類に基づいて使用する Web フォームの入力要素の種類を決定するルールがあります。

多くのヌル行効果を持つワイドテーブルを回避するために、一部のデータをリレーショナルに保存し、他のデータを拡張的に保存する必要がある場合、これは非常にうまく機能します。

データベース内の他のテーブルとの結合やピボットなど、データでリレーショナルなことを行う必要がない場合は、単純な自己完結型 XML フォームも適切なソリューションです。

現在、ほとんどのデータベースは、この種のことに対する最高クラスの XML サポートを備えています。たとえば、SQL Server では、XSD スキーマをデータベース内の XML データ型の列に適用できます。最近のバージョンでは、これらの列のインデックス作成もサポートされています。

于 2010-01-21T13:15:26.630 に答える