エンティティの特殊プロパティとデータベースの正規化

Question

すべての標準的な顧客プロパティ（名前、住所、連絡先など）を持つ顧客オブジェクトがあるとします。私たちは、私たちに送られる請求書にバーコードとして私たちのIDを持っているという非常に特殊な要求を持っている新しい顧客（Acme）を取得します。私たちはこれを他のすべての顧客には望んでいないので、Acmeの特別なケースとしてこれを行うつもりです。さて、多くの顧客がこれらの小さな一回限りのリクエストを持っているとしましょう。何がこのデータモードへの最善の方法のようになります。

私はカップルの可能性とそのメリット/トレードオフを参照してください。

1）ハードコードは、偏差の時点で、IDや顧客名のチェックを。
利点：最小限の労力、単一の統合点
トレードオフ：エラーが発生する可能性が非常に高い。フラグを変更するには、新しい展開が必要です。特性が増加するにつれて偏差を見つけるのは難しい。

2）各プロパティの顧客のDB列。 1つの顧客に対してフラグをtrueに設定し、残りのすべてに対してfalseに設定します。
利点：比較的単純で、即座にプロパティを変更できます。
トレードオフ：非常に幅の広いデータベースと厄介なスキーマを作成します。より多くのプロパティが追加されるにつれて、データはますます管理不能になります。多くの不必要なプロパティがマッピングされる必要があるので、コードが不安定になります。

3）ハードコードされたプロパティマッピング。顧客のための特別なプロパティを保持するマップ。マップは特別なプロパティのために要求することができ、コードフローはそこから出ることができます。
利点：単一の管理ポイント。
欠点：ハードコードされています。顧客ID /名前はコード内にあります。変更を加えるには導入が必要です。

4）キー/値列を持つCustomerPropertyテーブル。
利点：クリーン。管理の単一点。動的。
欠点：相対的な複雑さ、他のソリューションと比較します。

明らかに、選択は状況によって異なります。数百の偏差がある場合は、単一の管理ポイントを持つことが重要です。もしそれが本当に一回の逸脱だったなら、＃1は大丈夫だとは思いますが、ハッキリです。

私は自分の意見をもっていますが、その場合にはベストですが、他の人の意見を知りたいと思います。

Answer 1

私はオプション4を使用します。経験から、より速いオプションを選択した場合、結果は必然的に最適なソリューションの実装であり、ハックは問題の原因となりました。私は常にドメインの観点からこれらの問題にアプローチしようとしており、この場合は4が最良のモデルです。実装の違いは、すべての成果物のメンテナンスや最終的なリファクタリングのメンテナンスに比べて最小限です。

Answer 2

私は完全に正規化されたアプローチを選択します。プライマリキーを使用して、さまざまな一回限りの特別なリクエストを列挙したテーブルがあります。次に、2つの列、両方の外部キー、最初の列に顧客のID、2番目の列にIDを持つリクエストテーブルを持つ結合テーブルを作成します。

Answer 3

以前の私のプロジェクトでは1）多くのことを行い、最終的には数字4のような解決策に移行しました。カスタマイズ用のフックを配置するために私のハックの場所を使用しました。間違いなく、特にカスタマイズの要求が増えるにつれて、管理が容易でした。

私はもともと、他のクライアントも最終的には請求書にバーコードが必要であると想定していたため、2）はあなたの特定のシナリオ（想定された追加のカスタマイズ要求、バーコード要求）しかし、私は、最初の顧客のために最初に設計したものとは異なるフォーマットでバーコード情報を求めていることも知ることができます。

私は4）と言っているので、カスタマイズエンティティと顧客エンティティの間に多対多の関係を実装します。最初は、カスタマイズが行われるべきアプリケーションコードでswitch文を実行するために、カスタマイズのエンティティが値以上の値である必要はありません。