I'm trying to build a database for banking I created a table for every account loan, deposit , checking account and also for payment methods checks, debit cards and cash.
My question is that how should I handle transactions between the tables knowing that the transactions are possible between all the tables?
For example customer can withdraw money using debit card, transfer money from checking account to loan or deposit money to checking using a check.
My first solution is to create one transaction table for all the transactions and the Cardinality (0...1 n ) so that only one type of payment and one account, so should I go with it or just create a transaction table for every relationship between two tables?
If "I created a table for every account, loan, deposit , checking account" means that you have more than four tables then you are doing something very very wrong. You should have one table for customers and one table for transactions. A transaction is money moving from one account to another account, so a simple transaction table would have the fields id, transaction date, credit account, debit account, amount. In accountancy, there are frequently transactions which involve several credit and debit accounts so these can't be maintained in the simple transaction scheme outlined above.
If you want to represent loans, then you'll probably need two more tables: one table contains the atomic details of all the loans (date given, account of the loanee, total amount, nominal interest rate, etc) and the other table contains the projected repayments of each loan.
There is no need for further tables representing deposits or checking accounts: these can be represented as accounts, with a type field designating which kind they are.
Related
Suppose a user is able to
(1) use money to buy something (Money leaves wallet)
(2) sell something to earn money (Money enters wallet)
and I want to keep track of the transactions and ensure that they are accurate. And I have thought of two methods
(A) Keep track using three disjoint table
buys <userid, amount>
sells <userid, amount>
transaction <transactionid, userid, amount, type>
i.e.
insert <u1, 90> into buys trigger insert <t1, u1, 90, 'buy'>
for example
(B) Have buys and sells store transactionid from transaction table
buys <userid, transactionid>
sells <userid, transactionid>
transaction <transactionid, amount>
i.e.
insert <t1, 90> into transaction and insert <u1, t1> into buys
My questions will be what are the pros and cons to method (A) and (B) and what are the alternative methods/best practices out there?
You can do it like this:
user table: (userid, name, ...)
transaction table: (transactionid, amount, date, ...)
link user and transaction table, (transactionid, buyerid, sellerid).
buyerid and sellerid are foreing keys of user.userid.
This way, you can get buyer and seller form one single query, and not two tables. If you need to keep track of offered price and paid price, they are just extra fields in the transaction table.
So any data on the transaction goes in the transaction table, any data related to the involded users goes into the link table.
I see entities (users, transactions) as separate tables, and actions as link tables between entities.
System has many users belongs to a company. Admin user of the company can entry customers and each customer may have invoices with payment amount. The customer invoice amount need to be paid and should be inserted in double entry system in transaction master table.
Data Models are followings:
User
Company
Customer
Invoice
Transaction Master
My initial approach will be:
Company will have a one to many relationship with users
in invoice table, the details will be saved.
My questions are:
Do I need to create any relationship between customers and invoices tables?
How the transaction master table will be created? (double entry system refers to have debit and credit accounts, that's all my knowledge)
Yes, you need to create a relationship between customers and invoices table. Every invoice will have one customer. Every customer will have none, one, or many invoices. You will need a unique identifier to be stored in each file.
Transaction file is a much deeper subject. I assume you mean Ledger Transactions. Generally you will group a transaction with one or more debit entries matched with one or more credit entries with an associated reference number which will point to the invoice transaction. You would group references in a batch, usually called a session, and assign a session number at batch posting time which would have the post date.
These are the basic minimum answers to a very vague question on a potentially complex subject, but hopefully it will help get you started in the right direction for further research.
I was wondering how people are securely storing money balances in a database. E.g how do you make sure that the database administrator does not modify balances or transactions? How do you make sure that the code that does a transaction not accidentally or intentionally by a rogue employee does not work correctly.
Banks, PayPal and any other apps that hold balances in USD or any other currency should have this problem
All the banking packages I've worked with store the balance with the account entity. Calculating it on the fly from movement history is unthinkable.
The right way is:
The movement table has an 'opening
balance' transaction for each and every account. You'll need
this in a few year's time when you
need to move old movements out of the
active movement table to a history
table.
The account entity has a balance
field
There is a trigger on the movement
table which updates the account
balances for the credited and debited accounts. Obviously, it has commitment
control. If you can't have a trigger, then there needs to be a unique module which writes movements under commitment control
You have a 'safety net' program you
can run offline, which re-calculates
all the balances and displays (and
optionally corrects) erroneous
balances. This is very useful for
testing.
Some systems store all movements as positive numbers, and express the credit/debit by inverting the from/to fields or with a flag. Personally, I prefer a credit field, a debit field and a signed amount, this makes reversals much easier to follow.
Notice that these methods applies both to cash and securities.
Securities transactions can be much trickier, especially for corporate actions, you will need to accommodate a single transaction that updates one or more buyer and seller cash balances, their security position balances and possibly the broker/depository.
From smirkingman answer on Database design: Calculating the Account Balance
Let's say I have an app (a Monopoly game) with many users, where each user has a balance, and they make transactions between them.
I have a table with all the users (userID, name, email) and a table with all the transactions and the users who made them (user1, user 2, amount).
Now if I need to present a balance for each user, would it be better to keep the balance for each user in the users table and update it every time a transaction is made, or should I calculate it from the transactions table every time I wont to present it? Assume this game will have a lot of traffic, so what is a more reasonable approach for 10,000+ users and about 120,000+ transactions per week?
Having a new column balance in the user table is a redundancy beacause the value could be calculated with a query on the transactions table.
However one of the DB design process is the estimation of how many read and writes could happen on a particular table. If this estimation is high it's logic and permitted to simplify the result of some read or write and have a redundancy on the DB to afford the many reads requested by the web pages and display values with less processing time.
In your case the balance column update could be done with a trigger on the transactions table that calculate the balance for the two users involed.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Does anybody know or have any links to websites describing details of how to design a database schema for a double entry accounting system ??.
I did find a bunch of articles but non were very explanatory enough.
Would appreciate it if someone could help me on this.
Create the following tables
account
transaction
line_item
contact (can be a customer a supplier, or an employee).
To keep things simple, we will leave out the account_type table, contact_type table, etc.
Identify the relationships between the tables and set them up
a contact can have many transactions, but each transaction can only have one contact (one-to-many relationship)
an account can have many transactions, and one transaction can affect many accounts; line_item is the join table between transaction table and account table (a many-to-many relationship)
a transaction can have many line items, but each line item must relate to one transaction.
We have the following schema (a one-to-many relationship):
CONTACT ———< TRANSACTION ———< LINE_ITEM >——— ACCOUNT
Add appropriate fields to each table
Contact
contactID
name
addr1
addr2
city
state
zip
phone
fax
email
Transaction
transactionID
date
memo1
contactID
ref
Line_item
line_itemID
transactionID
accountID
amount
memo2
Account
accountID
account_name
account_type
Create as many new transactions as needed
For example to add a new transaction in the database, add a new record in the transaction table and fill in the fields, select a contact name, enter a date, etc. Then add new child records to the parent transaction record for each account affected. Each transaction record must have at least two child records (in a double-entry bookkeeping system). If I purchased some cheese for $20 cash, add a child record to the transaction record in the child record, select the Cash account and record −20.00 (negative) in the amount field. Add a new child record, select the Groceries account and record 20.00 (positive) in the amount field. The sum of the child records should be zero (i.e., 20.00 − 20.00 = 0.00).
Create reports in the database based on the data stored in the above tables
The query to give me all records in the database organized so that transaction line item child records are grouped by account, sorted by date then by transaction ID. Create a calculation field that gives the running total of the amount field in the transaction line_items records and any other calculation fields you find necessary. If you prefer to show amounts in debit/credit format, create two calculation fields in the database query have one field called debit, and another called credit. In the debit calculation field, enter the formula "if the amount in the amount field from the line_item table is positive, show the amount, otherwise null". In the credit calculation field, enter the formula "if the amount in the amount field from the line-Item table is negative, show the amount, otherwise null".
Based on this rather simple database design, you can continuously add more fields, tables and reports to add more complexity to your database to track yours or your business finances.
I figured I might as well take a stab at it. Comments are appreciated – I'll refine the design based on feedback from anyone. I'm going to use SQL Server (2005) T-SQL syntax for now, but if anyone is interested in other languages, let me know and I'll add additional examples.
In a double-entry bookkeeping system, the basic elements are accounts and transactions. The basic 'theory' is the accounting equation: Equity = Assets - Liabilities.
Combining the items in the accounting equation and two types of nominal accounts, Income and Expenses, the basic organization of the accounts is simply a forest of nested accounts, the root of the (minimum) five trees being one of: Assets, Liabilities, Equity, Income, and Expenses.
[I'm researching good SQL designs for hierarchies generally ... I'll update this with specifics later.]
One interesting hierarchy design is documented in the SQL Team article More Trees & Hierarchies in SQL.
Every transaction consists of balanced debit and credit amounts. For every transaction, the total of the debit amounts and the total of the credit amounts must be exactly equal. Every debit and credit amount is tied to one account.
[More to follow ...]