8

SQL Server バックエンドを使用して .NET アプリケーションを開発しています。クライアントは、アプリケーションがデプロイされた後、エンティティにカスタム属性を動的に追加する機能を要求します。

同様の質問で示唆されているように、各カスタム属性値の行を含むテーブルを作成できます (エンティティ属性値モデル)。ただし、エンドユーザーが実際にテーブルを変更できるようにすることを検討しています (同じ質問でも提案されています)。つまり、列の追加と削除です。

（編集：コメントに記載されているように、DDLはユーザーまたはアプリケーションによって直接実行されるのではなく、すべてがスムーズに実行されるようにストアドプロシージャを介して実行されます）

主な理由は次のとおりです。

  • パフォーマンスの向上/検索可能な属性
  • ほとんどの場合、属性は列として表示する必要があります。たとえば、ユーザー インターフェイスのデータ グリッドに表示する場合や、Excel/PowerPivot でさらに処理するためにデータを抽出する場合です。
  • データは厳密に型指定されます (すべての属性値を varchar として格納するのではなく)
  • 単純化されたデータ モデル

注意すべき点はありますか?

頭に浮かぶことは次のとおりです。

  • 変化するデータ構造を処理できない可能性があるバックアップ/復元操作
  • これらの変更を反映するように適切に更新されていない依存オブジェクト (ビューなど) (依存ビューはselect * from table、追加された列を含めるために を実行する必要があります)。
  • ...

このアプローチに関するご意見をお待ちしております。

4

1 に答える 1

2

これをさまざまな方法で処理するサードパーティのアプリケーションを使用しています。

  1. ほとんどのテーブルには、一般的な名前のデータ型 (Number1、Date26、Text3 など) を保持するさまざまなフィールドを備えた「カスタム」バージョンのテーブルがあります。したがって、1 対 1 の関係を持つ Company と CompanyCustom があります。

  2. リストは、ListID (およびユーザーがスキーマをセットアップするための対応する方法) とメイン テーブルにリンクするための外部キーを持つテーブルに作成されます。このテーブルには、#1 のような一般的な列がいくつかあります。

  3. 独自のテーブルを作成する

  4. 独自のビューとストアド プロシージャを作成し、アプリケーションに登録します。これらのデータセットは、データ グリッドに添付したり、カスタム レポートで使用したりできます。

ユーザーが適切と思われる列にラベルを付けることができるインターフェイスがあります (つまり、Text1 = "Blah Blah Blah")。この状況では多くの無駄なフィールドがあり (私の会社は Money47 を含むほとんどのフィールドを使用することができましたが)、これはパフォーマンスにとって理想的ではありません。

ここで重要なのは、このクライアントがこの機能と継続的なサポートに対していくら支払う気があるかということです。彼らに既存のテーブルにカスタム フィールドを作成させ、スムーズに変換されないデータ型を変更したいと判断した場合、彼らはあなたがそれをシャッフルして変換することを期待するでしょうか?

このシステムに支払った金額で、フルタイムのプログラマーを雇うことができます。SalesForce.com および同様のサイトには、この機能があります。1回限りのクライアントアプリでこれに取り掛かりたくないと思います。彼らは、長期的にはアプリを更新し続けるためにあなたにお金を払うかもしれません.

于 2013-01-22T19:00:25.860 に答える