Re: Need help trying to figure out accounting database schema

From: Ed Prochak <edprochak_at_gmail.com>
Date: Mon, 16 Jun 2008 12:06:05 -0700 (PDT)
Message-ID: <d5226f0c-3cf5-4dfa-b517-ce45ac5519da@2g2000hsn.googlegroups.com>


On Jun 15, 10:01 pm, jmDesktop <needin4mat..._at_gmail.com> wrote:
> 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.

look up entity Relationship Diagram (ERD) 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 Received on Mon Jun 16 2008 - 14:06:05 CDT

Original text of this message