住宅社会管理システムのデータベース構造

Question

私は昨日、住宅社会の請求構造を設計しています。私はグーグルで銀行請求の構造を考え、データベース構造を設計しましたが、これが正しいかどうかはわかりません。だから私は請求データベースの構造を入れています。

私のデータベース構造でどこで変更が行われなければならないか間違っていると教えてください。

さらに、私は社会保険残高（デビット、クレジット）を掲示しなければならないことがあります。保険証書や収入ビルディングのような収入、バランス監査証跡についてはわかりませんFKとしてのID）。

時間を変更し、すべてのテーブルが作成したデフォルトで持つことになりますのでご注意ください、によると、IPアドレス

表のbillingstatement

id | description      | amount | Bill Month | userId | societyId 
1 | Maint Chrg 1000 sqft x 5 per sqft | 5000 | Aug-16  | 1001  | 101  
2 | Water Charges      | 200 | Aug-16  | 1001  | 101  
3 | Construction Charges    | 300 | Aug-16  | 1001  | 101 
4 | Reserved Parking chrgs    | 500 | Aug-16  | 1001  | 101 

表は

id | balance(current bal) | societyId | modifiedTime   | 
1 | -6000    | 101  | 2016-01-01 21:01:01 | 
2 | -5000    | 101  | 2016-01-01 21:01:01 | 
3 | 1000     | 101  | 2016-01-01 21:01:01 | 

表アカウントトランザクション

id | amount | balance | trans_type | trans_time   | account_id | 
1 | 6000 | 0  | 1  | 2016-01-01 21:01:01 | 1   | 
2 | 5500 | -6000 | 1  | 2016-02-01 21:01:01 | 2   | 

tran_type :- 1 = Payment by user, 2 = Income to society, 3 = Expense to society 

表のmap_account_user

map_id | account_id | user_id 
1  | 2   | 1001 

アカウントのマッピングが存在しない場合、それは、それが社会のアカウントではなくユーザーアカウントであることを意味します。

参考： -

billing banking desing

banking project sample

Answer 1

私はあなたがリレーショナルデータベースを設計していると仮定しています。リレーショナルデータベースでは、normalizeというデータがあります。

idというフィールドが多すぎるため、データベース設計に問題があります。各idフィールドは一意の名前を取得する必要があるため、異なるidフィールドがどのようなものであるかを人々が知ることができます。

まず、トランザクションテーブルから始めましょう。一般にテーブル名は単数形です。私はテーブル名とカラム名を大文字にします。あなたはその大会に従う必要はありません。

Transaction 
----------- 
Transaction ID 
Transaction Type 
User ID 
Society Account 
Transaction Amount 
Transaction Time Stamp 
... 

トランザクションIDは自動インクリメント整数です。また、Transactionテーブルのプライマリ（クラスタリング）キーです。取引タイプは1 =ユーザによる支払い、2 =社会への収入、3 =社会への費用です。取引タイプ1と取引タイプ2の違いはわかりません。

ユーザーIDまたは社会勘定科目列が入力されています。取引ID 1欄には取引タイプ1と社会勘定取引タイプ2と3に対して、列が記入されます。記入されていない列は、NULLに設定されます。

取引金額は常に正の値です。あなたのコードは、取引タイプ3のソーシャルアカウントから取引金額を差し引きます。

（ユーザーID、取引タイムスタンプ降順、取引ID）とユニークなインデックスを作成します（ソーシャルアカウント、取引時間スタンプ降順、トランザクションID）。これにより、特定の月のユーザーまたは社会のアカウントのすべての取引をすばやく取得できます。

次に、UserAccountBalanceテーブルを見てみましょう。

UserAccountBalance 
------------------ 
User ID 
Balance Year and Month 
Balance Amount 
... 

このテーブルの主キーは、（ユーザーID、残高年、月降順）です。各ユーザIDについて、毎月の履歴残高を更新します。これにより、監査人は取引テーブルに対してクエリを実行することによって残高を確認することができます。

次に、SocietyAccountBalanceテーブルを見てみましょう。

SocietyAccountBalance 
--------------------- 
Society Account 
Balance Year and Month 
Balance Amount 
... 

この表はUserAccountBalance表に似ていますが、ソーシャルアカウント用です。

次は、Billingテーブル

Billing 
------- 
User ID 
Billing Year and Month 
Billing Type 
Square Feet 
Charge per Square Foot 
Total Charge 
...  

主キーがある（ユーザID、課金年と月は下降、請求タイプ）を見てみましょう。私は1ヶ月あたりの課金タイプごとに課金料金を1つしか得られないと仮定しています。

請求タイプは1 =保守料、2 =水道料金、3 =建設料金、4 =予約駐車料金です。この表の値から請求書にテキストを生成することができるので、テキストをデータベースに格納する必要はありません。請求タイプ1の場合は、平方フィートおよび平方フィート当たりの費用が記入されます。そうでない場合は、ゼロです。

お支払いは請求書と一致させる必要がありますが、適切な経路で開始するには十分です。

Answer 2

は本当にあなたの努力のために感謝しています。あなたは銀行システム上の参照は本当に最高のアプローチです。私はあなたのためにそれが良いと感じる場合、あなたに役立ついくつかのアイデアを提供したいと思います。行のNOが減少して以来のことだろう、あなたの
{水道料金
建設
予約駐車chrgsを充電}新しい列として
、 -

はあなたの記述の列のデータを使用している場合は
、起動できます効率的なデータ保守が可能です。ユーザーIDごとに、4行を維持するのではなく、1行のデータを持つことができます。提供された例を確認してください。 sq ftごとに個別に説明列を付けることができます。expenseBldginsurance
として

id | userId | societyId | BillMonth | MaintChrg | WaterCharges | ConstructionCharges | ReservedParkingCharges | Description 
1 | 1001 | 101  | Aug-16 | 5000  | 200   | 300     | 500     | Maint Chrg 1000 sqft x 5 per sqft 
2 | 1002 | 101  | Aug-16 | 4000  | 200   | 300     | 500     | Maint Chrg 900 sqft x 5 per sqft 
3 | 1003 | 102  | Aug-16 | 5000  | 200   | 300     | 500     | Maint Chrg 900 sqft x 5 per sqft 

あなたは借方と貸方の使用に疑問について、
デビット クレジット前売ボードとして
を買いだめまた、ユーザー名などのかもしれない他の列、人々のいいえ、電気料金.etcを追加することはできません。 、。
あなたに役立つことを願っています。より明確にする必要がある場合は、コメントを記入してください。

Answer 3

私はエンティティに集約を格納することに躊躇しています。集約を計算することが非常に難しい場合を除いて、詳細を調べることによって、集計を常に考慮する必要があります。

Answer 4

構造が機能します。私はIDの名前を少し変えるだろう。

account_idはいくつかの場所で参照されていますが、アカウントテーブルではIdです。

私はAccountテーブルのaccount_idにします。これにより、データベースのユーザーが参加できる場所を簡単に特定できます。 "Account_Id"と呼ばれる場所はすべて、それを生成する単一のマスター表を持つ同じAccount_Idでなければなりません。