Option 1) user can have multiple "accounts" (eg payment, deposits, withdraws etc)
Option 2) user can only 1 single account, and transaction has types (payment, deposit, withdraw)
Both option will work just fine! They both can produce the same result! However option 1 uses more resources, but it's more flexible, option 1 is not flexible but uses less resources!
What is the question ?
Option 1 is a piece of garbage, that no accountant can use, and no auditor will pass. payment, deposits, withdraws eta re transactions, not "accounts". So what if it uses less resources. SO do cave men.
Option 2 starts to look like an accounting system, with (a) accounts and (b) transactions against accounts, as expected in most developed countries.
So there is no choice.
Start from a journal table, that link to a chart of accounts table. In your journal table is where you will store fieldnames for transaction date, account code, description, amount. chart of account table is where you will store fieldnames like account code, account type (balance sheet or profit and loss),account status (active or inactive). For greater details on the accounting database schema, download derek liew's book on accounting database design.
Related
I have a small data warehouse for Sales. Here i have Fact Table for Sales Invoices and Dimensions like customer, Date Time, Sales Geo, Product Code.
Fact Table: Sales - >
Invoice Date, Customer code, Product Code, Sales Geo Code, Billing qty, Amount, Tax, Total Amount
For Sales Geo dimension - >
Sales Geo Code, City Name, Regional Code, Zone Code, Regional Manager Code, Zonal Manager code
I have confusion in how to link my sales persons like Regional Manager and Zonal Managers etc.
Regional Manager is leading one region of multiple cities,
zonal manager is leading multiple region.
Sometimes we change the regional area or zonal area, they get promoted, they left etc.
How to create dimension and link sales team with Sales Fact to get correct Sales report.
regards
there are a few options I can think of:
Denormalise the Regional and Zonal Manager information into your Sales Geo Dimension
Create a hierarchical Manager dimension keyed on Regional Manager and including their zonal manager details
Create a Person Dim and associate it twice to the Fact - once in the role of Regional Manager and once in the Role of Zonal Manager
If you will never want to link Manager information to a fact except in the context of the Sales Geo then option 1 probably makes more sense - as you have fewer potential joins in queries using this fact table.
Option 2 is more flexible as you can associate manager information to a fact without also using the Sales Geo
Option 3 is the most flexible but also likely to give the worst query performance (for any query that needs both types of manager) and also the only link between Regional and Zonal managers is via the Fact; there is no hierarchical information held in the Dimensions. Therefore option 3 is the one I would be least likely to choose
Denormalize the Regional Manager Code and Zonal Manager code in your fact table.
So basically you will store in each fact row along with the Sales Geo Code also the current assignment of the two manager roles at the time of the sales (more precise at the time of the loading the record).
This model allows both types of the reports using
managers assigned at the transaction time (direct from the fact table) and
current managers (join from the fact table to Sales Geo dimension to get the code of the both managers)
Now your setup allows only the second type of the reporting, which could be suboptimal in case that the managers are frequently re-assigned.
If you prefer not to denormalize the fact table you can always switch the Sales Geo dimension to SCD type 2 which will introduce a historical view on the dimension and the assignment of the managers.
You'll have to join not only with the Sales Geo Code from the fact table to the Sales Geo dimension but also considering the transaction date...
Invoice_Date between sales_geo.validfrom_date and sales_geo.validto_date
... to get the managers assigned at the time of the transaction.
The decision has a typical tradeoff between storage plus maintaining the consistency and more complex joins plus maintaing the dimension history on the other side.
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
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.
I'm designing a database that will hold a list of transactions. There are two types of transactions, I'll name them credit (add to balance) and debit (take from balance).
Credit transactions most probably will have an expiry, after which this credit balance is no longer valid, and is lost.
Debit transactions must store from which credit transaction they come from.
There is always room for leniency with expiry dates. It does not need to be exact (till the rest of the day for example).
My friend and I have came up with two different solutions, but we can't decide on which to use, maybe some of you folks can help us out:
Solution 1:
3 tables: Debit, Credit, DebitFromCredit
Debit: id | time | amount | type | account_id (fk)
Credit: id | time | amount | expiry | amount_debited | accountId (fk)
DebitFromCredit: amount | debit_id (fk) | credit_id (fk)
In table Credit, amount_debited can be updated whenever a debit transaction occurs.
When a debit transaction occurs, DebitFromCredit holds information of which credit transaction(s) has this debit transaction been withdrawn.
There is a function getBalance(), that will get the balance according to expiry date, amount and amount_debited. So there is no physical storage of the balance; it is calculated every time.
There is also a chance to add a cron job that will check expired transactions and possibly add a Debit transaction with "expired" as a type.
Solution 2
3 tables: Transactions, CreditInfo, DebitInfo
Transactions: id | time | amount (+ or -) | account_id (fk)<br />
CreditInfo: trans_id (fk) | expiry | amount | remaining | isConsumed<br />
DebitInfo: trans_id (fk) | from_credit_id (fk) | amount<br />
Table Account adds a "balance" column, which will store the balance. (another possibility is to sum up the rows in transactions for this account).
Any transaction (credit or debit) is stored in table transactions, the sign of the amount differentiates between them.
On credit, a row is added to creditInfo.
On debit one or more rows are added to DebitInfo (to handle debiting from multiple credits, if needed). Also, Credit info row updates the column "remaining".
A cron job works on CreditInfo table, and whenever an expired row is found, it adds a debit record with the expired amount.
Debate
Solution 1 offers distinction between the two tables, and getting data is pretty simple for each. Also, as there is not a real need for a cron job (except if to add expired data as a debit), getBalance() gets the correct current balance. Requires some kind of join to get data for reporting. No redundant data.
Solution 2 holds both transactions in one table, with + and - for amounts, and no updates are occurring to this table; only inserts. Credit Info is being updated on expiry (cron job) or debiting. Single table query to get data for reporting. Some redundancy.
Choice?
Which solution do you think is better? Should the balance be stored physically or should it be calculated (considering that it might be updated with cron jobs)? Which one would be faster?
Also, if you guys have a better suggestion, we'd love to hear it as well.
Which solution do you think is better?
Solution 2. A transaction table with just inserts is easier for financial auditing.
Should the balance be stored physically or should it be calculated (considering that it might be updated with cron jobs)?
The balance should be stored physically. It's much faster than calculating the balance by reading all of the transaction rows every time you need it.
I am IT student that has passed a course called databases, pardon my inexperience.
I made this using MySQL workbench can send you model via email to you do not lose time recreating the model from picture.
This schema was made in 10 minutes. Its holding transactions for a common shop.
Schema explanation
I have a person who can have multiple phones and addresses.
Person makes transactions when he is making a transaction,
You input card name e.g. american express,
card type credit or debit (MySQL workbench does not have domains or constrains as power-designer as far as i know so i left field type as varchar) should have limited input of string debit or credit,
Card expiry date e.g. 8/12,
Card number e.g. 1111111111
Amount for which to decrease e.g. 20.0
time-stamp of transaction
program enters it when entering data
And link it to person that has made the transsaction
via person_idperson field.
e.g.
1
While id 1 in table person has name John Smith
What all this offers:
transaction is uniquely using a card. Credit or Debit cant be both cant be none.
Speed less table joins more speed for system has.
What program requires:
Continuous comparion of fields variable exactTimestamp is less then variable cardExpiery when entering a transaction.
Constant entering of card details.
Whats system does not have
Saving amount that is used in the special field, however that can be accomplished with Sql query
Saving amount that remains, I find that a personal information, What I mean is you come to the shop and shopkeeper asks me how much money do you still have?
system does not tie person to the card explicitly.
The person must be present and use the card with card details, and keeping anonymity of the person. (Its should be a query complex enough not to type by hand by an amateur e.g. shopkeeper) , if i want to know which card person used last time i get his last transaction and extract card fields.
I hope you think of this just as a proposition.
In your accounting software how would you design your accounts database for COA
Design 1) 1 account can hold 1 currency only
Design 2) 1 account can hold multi currency, just filter the transaction by CurrencyId (USD, GBP etc..)
Design 1) 1 account can hold 1 currency only
ACCOUNT
Id
AccountNumber
CurrencyCode
...
TRANSACTION
Id
AccountId
Amount
...
Design 2) 1 account can hold multi currency
ACCOUNT
Id
AccountNumber
...
TRANSACTION
Id
AccountId
Amount
CurrencyCode
....
In the first place, I wouldn't design accounting software. I'd buy it. Accounting is one of the fields where you need domain experts (that is, accountants) helping to develop the software.
In the second place, if you're required to accept multiple currencies, then you have to store the type of currency along with the value. In a system like that, a debit of 30 is meaningless. Only debits of 30 USD or 30 EUR are meaningful.
But storage is the simplest part of your problem. How are you going to add up transactions involving multiple currencies? There's more than one way to do that, there's probably more than one "right" answer, and your accountants will probably come to blows over which way is the "right" way.
You could use existing services as a guide - e.g., Paypal.
In Paypal, for each account you have to nominate the base currency for that account. Then, any transactions are converted to that currency before being applied to the account. The original amount, its currency, and the conversion rate applied at the time, could also be stored alongside, but for doing calculations you'd use the base currency.
As a general safety rule, always go for the more flexible design. In this interconnected world, it is almost certain that there will be transactions in all kind of currencies (except maybe the local car boot sale, although I am not sure about it). So, store the currency code in the transaction table.