 | |
Need help trying to figure out accounting database schema
comp.databases.oracle.server comp.databases.oracle.server
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Need help trying to figure out accounting database schema -
06-15-2008
, 10:01 PM
#2
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
#3
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
#4
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
#5
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
#6
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
#7
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
#8
| |||
| |||
|
|
For an accounting / banking database, I have the following in a two transaction tables showing what someone spends or credits: Transaction Table //one only -- TransactionID UserID TransactionItemID Table //many -- TransactionItemID TransactionID ItemID AccountTable //one to one from TransactionID Table -- AccountID TransactionItemID UserID Debit Credit Balance One transcation, many items tied to that single transaction. Results of that transaction put in the account table. Is this right or too many tables? In my logic I can change the balance and a purchase or debit was incurred. I would have to have a starting balance to begin with (but what if it is the first transaction? I'd have not item and a blank transactionitemid.) It would simply be a credit when the user first starts using the database for that account and as they went along simple addition and subtraction for each item tied to a single transactionid. Should the transaction table have the debit, credit, and balance table in it? Am I thinking about schema wrong? I couldn't find any example accounting or banking database schemas online to learn from for this (the ones I found didn't have what I wanted.) Thank you for any insight. |
Learn about logical design before you get down to the "physical"
design (i.e. the level of tables). Fact is there are essentially no
right/wrong answers. There are good/poor design however based on what
you are modeling and how it is intended to be used. A design that is
poor for one application may be great for another.
HTH,
Ed
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.