エンドユーザーがカスタムフィールドをデータベーステーブルに追加できるアプリを構築しています。 CRMアプリのようなものだと考えてください。顧客のテーブルにフィールドを追加する必要がある場合があります。ほとんどすべてのCRMにこの機能があります。従来のSQLデータベースを使用しています。
ALTER TABLE ADD列を介してデータ構造自体を変更することでそれを行う必要がありますか?または、新しいフィールドの内容をキー/値のペアとして別のテーブルに保存する必要がありますか(例:(id、fieldname、fieldvalue))?
ALTER TABLEの利点は、よりシンプルなことです。別のテーブルの利点は、エンドユーザーにALTER TABLEを許可することで、意欲を発揮できることです。
別のテーブルの大きな欠点は、どこでも醜い結合を使用する必要があるため、クエリが非常に複雑になることです。
とにかく、ほとんどのアプリはどのようにそれを行いますか?
少しモンゴっぽくして、カスタムフィールドを[〜#〜] json [〜#〜]としてテキストフィールドに保存できます。 MySQLとPostgresの新しいバージョンでは、これらについてクエリを実行することもできます。
つまり、これらのフィールドは、実際のデータベースフィールドの多くがnullでいっぱいになるのではなく、それらを必要とする行のみにあることを意味します。
ある種のデータディクショナリが必要になる場合があります-おそらくテーブル内にあるため、各カスタムフィールドの処理方法がわかります。
私が見た2つの方法は、あなたが言及したようにキー/値であるか、または開発者が固定数のフィールドを追加するだけの場合がありますCustom1
、Custom2
、... Custom10
データベースに。顧客に、必要に応じて使用できるフィールドは10個までという制限があることを伝えます。
ALTER TABLEはスケーリングしません。ほとんどがNULLになる何百ものユーザー定義の列が必要になり、テーブルが大きく、誰かが列を追加しようとすると問題が発生します。
私がそれらを見るとオプション:-
(最初のカップルはすでにDan Pichelmanによって提案されています)
1)Custom1..CustomNNテーブル(NN行を含む)を使用して、カスタムフィールドに意味のある名前と検証を割り当てます。
2)追加のフィールドを定義するためのテーブルと、このテーブルに主キーをリンクするための別のテーブルを必要とするKey-Valueペア。
これらのアプローチはどちらも、データ型の問題に終わります。 VARCHARに格納された整数。
3)プラグインアーキテクチャ-オープンソースCRMと同様に、インストール時にスキーマの変更を作成し、プラグインを操作するツールを提供するプラグインを中心にアーキテクチャを設計します。技術を重視するユーザーが必要です。
4)コンサルティングアプローチA-他のユーザーと共有される新しいフィールドを追加するように人々に支払います。利点-まだサポートするコードベースは1つだけです。欠点-独占権がないため、多くを請求することはできません。また、顧客は誰かが他の人に穴を開けて支払うのを待って無料にすることができます。これを回避する方法はいくつかあります。
5)コンサルティングアプローチB-支払いを希望するすべてのユーザーのために製品をカスタマイズし、新しいフィールドを他の顧客と共有しません(彼らが同様に支払いを行わない限り)。利点-1時間あたりの課金率が高く、同じ変更に対して多くのユーザーに請求できます。短所-コードベースの断片化、誰が何に対して何を支払ったかを管理します。永続的な独占権ではなく一時的な独占権を販売することで、部分的に緩和されます。