2

複数の顧客に SAAS として販売されているアプリケーションがあります。予想通り、顧客は独自のフィールドを追加してアプリケーションの一部の領域をカスタマイズしたいと考える場合があります。、具体的にはアクション/プロジェクトの追跡に関連する領域です。現在、これを少量許可しています。これは、各顧客の追加フィールドの名前を各フィールドの ID とともに db に格納することによって処理されます。次に、任意の値が、潜在的なデータ型 (文字列、日付など) ごとに列を持つ 2 番目のテーブルに格納されます。このテーブルは、カスタム フィールドの ID と、それが関連付けられているオブジェクトのキーを参照します。このようにして、すべてのカスタム フィールド データを 1 つのテーブルに格納することになります。少数の顧客向けのフィールドに限定されていれば、私はこれについてあまり気にしませんでしたが、現在では、販売および顧客サービスが個々の顧客向けにアプリケーションを迅速にカスタマイズする機会と見なされており、場合によっては問題のアイテムに元々あったよりも多くのカスタムフィールドを取得しています。

私は、これらの大規模なカスタマイズを今のところ保留するべきだと人々に確信させました。また、この種の動作が必要な場合は、適切に構築する必要があるという一般的な意見です。つまり、関連するデータベース テーブルなどを作成します。データベースでこれを実装する2つの方法について言及している別の質問here。1 つの解決策は、上で概説したものと似ています。もう 1 つは、カスタマイズするテーブルに Text1、Text2、Date1、Date2 などと呼ばれる冗長なフィールドを多数用意することです。これらのフィールドは、必要に応じてユーザーが GUI で適切に名前を変更して使用できます。

私は疑問に思っていましたが、他の誰かがこの問題をどのように解決しましたか? 彼らのソリューションにはどのような制限がありましたか? そして、私が行う可能性のあるさらに読むための提案。

乾杯、

4

1 に答える 1

1

また、SaaS の開発も行っており、あらゆる種類のカスタマイズを希望する顧客もいます。

多かれ少なかれすべての顧客にとって役立つ可能性がある場合、実装は固定されています。意味、テーブルとフィールド。この機能は、ユーザー パッケージに属する何らかのアクセス権によって有効または無効にされます。

また、ユーザーがフィールドとそれに関連するサブフィールドを動的に定義して独自のフォームを作成できる場合、別の状況もあります。それはそれが行くのと同じくらい複雑です。ここでは、ある種のエンティティ属性値モデルを使用して、これらのニーズに対応します。

これが「エンタープライズ」アプリケーションの特徴であり、おそらくその独自の機能です。顧客はエキゾチックなものを求めており、ノーとは言えません。

于 2009-09-21T14:47:07.197 に答える