複数の顧客に SAAS として販売されているアプリケーションがあります。予想通り、顧客は独自のフィールドを追加してアプリケーションの一部の領域をカスタマイズしたいと考える場合があります。、具体的にはアクション/プロジェクトの追跡に関連する領域です。現在、これを少量許可しています。これは、各顧客の追加フィールドの名前を各フィールドの ID とともに db に格納することによって処理されます。次に、任意の値が、潜在的なデータ型 (文字列、日付など) ごとに列を持つ 2 番目のテーブルに格納されます。このテーブルは、カスタム フィールドの ID と、それが関連付けられているオブジェクトのキーを参照します。このようにして、すべてのカスタム フィールド データを 1 つのテーブルに格納することになります。少数の顧客向けのフィールドに限定されていれば、私はこれについてあまり気にしませんでしたが、現在では、販売および顧客サービスが個々の顧客向けにアプリケーションを迅速にカスタマイズする機会と見なされており、場合によっては問題のアイテムに元々あったよりも多くのカスタムフィールドを取得しています。
私は、これらの大規模なカスタマイズを今のところ保留するべきだと人々に確信させました。また、この種の動作が必要な場合は、適切に構築する必要があるという一般的な意見です。つまり、関連するデータベース テーブルなどを作成します。データベースでこれを実装する2つの方法について言及している別の質問here。1 つの解決策は、上で概説したものと似ています。もう 1 つは、カスタマイズするテーブルに Text1、Text2、Date1、Date2 などと呼ばれる冗長なフィールドを多数用意することです。これらのフィールドは、必要に応じてユーザーが GUI で適切に名前を変更して使用できます。
私は疑問に思っていましたが、他の誰かがこの問題をどのように解決しましたか? 彼らのソリューションにはどのような制限がありましたか? そして、私が行う可能性のあるさらに読むための提案。
乾杯、