☰

アプリケーションでカスタムフィールドをサポートするためのデザインパターンは何ですか? 質問する

tag-icon • tag-icon database-design data-modeling
アプリケーションでカスタムフィールドをサポートするためのデザインパターンは何ですか? 質問する

当社は商用アプリケーションを開発しています。顧客からカスタム フィールドのサポートを求められています。たとえば、顧客フォームにフィールドを追加したいとします。

フィールド値とフィールドに関するメタデータを保存するための既知の設計パターンは何ですか?

今のところ、次のオプションが表示されます:

オプション1: varchar 型の Field1、Field2、Field3、Field4 列を Customer テーブルに追加します。

オプション2: 顧客テーブルに XML タイプの列を 1 つ追加し、カスタム フィールドの値を xml に保存します。

オプション3: varchar 型の列を持つ CustomerCustomFieldValue テーブルを追加し、その列に値を格納します。そのテーブルには、CustomerID と CustomFieldID も含まれます。

CustomerID,  CustomFieldID, Value
10001,       1001,          '02/12/2009 8:00 AM'
10001,       1002,          '18.26'
10002,       1001,          '01/12/2009 8:00 AM'
10002,       1002,          '50.26'

CustomFieldID は、CustomFieldID、FieldName、FieldValueTypeID の列を持つ CustomField という別のテーブルの ID になります。

オプション4: それぞれの可能な値の型の列を持つ CustomerCustomFieldValue テーブルを追加し、右側の列に値を格納します。#3 と似ていますが、フィールド値は厳密に型指定された列を使用して格納されます。

CustomerID,  CustomFieldID, DateValue,           StringValue,       NumericValue                 
10001,       1001,          02/12/2009 8:00 AM,  null,              null
10001,       1002,          null,                null,              18.26
10002,       1001,          01/12/2009 8:00 AM,  null,              null
10002,       1002,          null,                null,              50.26

オプション5: オプション 3 と 4 では、単一の概念 (顧客) に固有のテーブルを使用します。クライアントは、他のフォームでもカスタム フィールドを求めています。代わりに、システム全体のカスタム フィールド ストレージ システムを用意する必要がありますか? CustomerCustomFieldValue、EmployeeCustomFieldValue、InvoiceCustomFieldValue などの複数のテーブルを使用する代わりに、CustomFieldValue という名前の単一のテーブルを使用します。私にはその方がエレガントに思えますが、パフォーマンスのボトルネックが発生するのではないですか?

これらのアプローチのいずれかを使用したことがありますか? 成功しましたか? どのアプローチを選択しますか? 他に検討すべきアプローチをご存知ですか?

また、私のクライアントは、カスタム フィールドが他のテーブルのデータを参照できるようにしたいと考えています。たとえば、クライアントは顧客に「お気に入りの支払い方法」フィールドを追加したい場合があります。支払い方法は、システムの他の場所で定義されます。これにより、「外部キー」という主題が図に現れます。カスタム フィールド テーブルに保存されている値が有効な値であることを保証するために、制約を作成する必要がありますか?

ベストアンサー1

オプション 3、4、または 5 が適切である可能性が高いという以下の投稿者の意見には同意します。ただし、提案された実装にはそれぞれ利点とコストがあります。特定の要件に合わせて 1 つを選択することをお勧めします。例:

  1. オプション 1 の利点: 実装が迅速です。カスタム フィールドで DB アクションを実行できます (検索、並べ替え)。オプション
    1 の欠点: カスタム フィールドは汎用的であるため、厳密に型指定されたフィールドはありません。データベース テーブルは非効率的で、サイズ的に、使用されることのない無関係なフィールドが多数あります。許可されるカスタム フィールドの数を予測する必要があります。
  2. オプション 2 の長所: 実装が迅速。柔軟性があり、任意の数とタイプのカスタム フィールドを許可します。
    オプション 2 の短所: カスタム フィールドで DB アクションを実行できません。後でカスタム フィールドを表示するだけの場合、または顧客ごとにデータの小さな操作のみを行う場合は、これが最適になります。
  3. オプション 3 の長所: 柔軟性と効率性の両方を備えています。DB アクションを実行できますが、データは無駄なスペースを削減するためにある程度正規化されます。タイプまたはソース情報を指定するために使用できる追加の列を追加するという、不明な (google) の提案に同意します。オプション 3 の短所: 開発時間とクエリの複雑さがわずかに増加しますが、ここではそれほど多くの短所はありません。
  4. オプション 4 はオプション 3 と同じですが、型付けされたデータを DB レベルで操作できる点が異なります。オプション 3 のリンク テーブルに型情報を追加すると、アプリケーション レベルでより多くの操作を実行できますが、DB では比較や並べ替えなどを実行できなくなります。オプション 3 とオプション 4 の選択は、この要件によって異なります。
  5. オプション 5 はオプション 3 または 4 と同じですが、ソリューションをさまざまなテーブルに適用できる柔軟性がさらに高まります。この場合のコストは、このテーブルのサイズがはるかに大きくなることです。カスタム フィールドにアクセスするために多くのコストのかかる結合操作を実行している場合、このソリューションは適切に拡張できない可能性があります。

PS 下記で説明するように、「デザイン パターン」という用語は通常、オブジェクト指向プログラミングを指します。データベース設計の問題に対する解決策を探しているので、デザイン パターンに関するほとんどのアドバイスは適用できません。

おすすめ記事