私は、バランスと支払いをどのように割り当てられているかを示すために異なる「マネーバケット」に分割する必要があるデータベースを持っています。たとえば、元本、利息、延滞料、バウンスされた小切手手数料、その他があります。最大10種類のお金バケットがあります。複数の部分に分割された天びんに適したテーブルデザインはどれですか？
この2つの方法のどちらを使用してデータベースを設計するのがよいでしょうか？なぜですか？
オプション
PAYMENTS
AccountId
// Other payment-related columns
TotalPaid
PrincipalPaid
InterestPaid
MiscPaid
BadCheckChargesPaid
...
オプションB
オプションBを使用しているほとんどの場合、異なるバランスタイプのみ1-3で
PAYMENTS
AccountId
// Other payment-related columns
TotalPaid
PAYMENT_DETAILS
PaymentId
PaymentTypeId
AmountPaid
より良い正規化、より柔軟な選択肢であります（後で新しいバケツを追加するのは簡単です）、私の投票権が得られます。
+1正規化されているだけでなく、正規化されたオプションでは、バケットごとに複数のエントリが許可され、すべてのエントリが個別に追跡されるためです。金融アプリでは、これはほぼ普遍的に絶対必要です。 –
標準化の妖精は、しばしば後者の方向にあなたを誘惑することができますが（私のように）、前者はおそらくより賢明です。あなたはたった10列（500ではない）を話しているだけで、実際に壊れている正規化ルールはありません。この支払い割り当てバケットのリストが成長する可能性が高い場合を除いて、EAV構造から離れることになるのは、それが生成できる頭痛（およびいくつかのクエリの無数の結合）のためです。
「正規化の妖精」は私を強く誘惑しています.... :) – Rachel
@レイチェル：それも私を誘惑します。 EAVは罰金や虐待の可能性があることはわかっていますが、構造が好きなのでEAVは私にとって悪です。 –
私はオプションBがEAVのアプローチだとは思わない。各レコードは明確に定義された項目で、支払いの詳細です。型の安全性には問題はなく、列方向のアプローチよりも、ユーザーがアプリケーションに必要なもの（詳細ごとに別々の行、下部に合計がある）に近いと思われます。 –
オプションBは私にとっては良いようです。決め手は、アプリケーションがこのような詳細情報を表示するように設計されているかどうかを次のようになります。
Item Amount
-------------- ---------------
Principal $10.00
Interest $1.11
ので、正規化されたバージョンは「righter」だけではありませんが、実際にアプリケーションが必要とするものに近い形式でデータを保存する場合。
私にとっては、支払記録に支払い合計を保存するのか、詳細からそれを引き出すのかという大きな疑問があります。
ほとんどの場合、ユーザーは総支払い額のみを気にします。彼らが詳細に興味がある場合は、ここに表示されたフォームでどのように分割されているかについての詳細を表示するために、支払いエントリをクリックすることができます。 – Rachel
マネーバケット？ "T"アカウントのように聞こえる...ほとんどの場合、DEBITSとCREDITSという2つのカラムと、関心を示すタイプコードなどが必要です。 1つの列から離れて、借方や貸方を示すためにマイナス記号を使用することができます（元帳勘定によって異なります）。 –
私はここに空のバケツをいくつか持っています。 。 。 –