online credit system table layout for transaction destinations foreign key

I'm trying to figure out how to properly store foreign keys when the key points to a different table based on a type.

I searched but nothing I found seemed to help at all.

There is a single table that will store most of the basics for the credits:

user_accounting
--------------------
user_accounting_id      (PK)
user_id                 (FK)
amount              
type                    (+deposit, +credit, -transfer, -purchase)
credit                  (bool, so I don't have to always check if amount is < or > 0)
void                    (in case it was canceled and repaired with some other transaction)
date
details                 (notes)

type s:

deposit - for outsite money being put into the system.
credit - are for money being transfered into their account from another
transfer - for putting money into someone elses account
purchase - for purchasing a site item

So far so good. This next part I'm a bit befuddled with. It will also have to store where the money is going to or coming from.

I'd like to store the foreign key for whatever type would indicate it's from. So if it's a purchase it will store the FK for the invoice_id, if it's a deposit it'll store a transaction_id from the merchant provider, if it's a transfer it'll store the user_accounting_id of the credit, if it's a credit it'll store the user_accounting_id of the transfer.

I'd be nice to have a single column storing that:

user_accounting (con't)
-----------------------------
source_or_destination_id (FK)

But I know that I can't have a single column be a foreign key linking to different tables based on type. So I could just store it as an (int) but it would be a huge pain to try to do JOINs with that id with different tables based on the type. Tried to do that a long time ago, big mistake.

So instead, I could do this instead:

user_accounting (con't)
-----------------------------
invoice_id                  (FK)
transaction_id              (FK)
credit_user_accounting_id   (FK)
transfer_user_accounting_id (FK)

But yet again that a big problem since I create an exclusive arc which isn't good.

I could also use a many_to_many_through relation for the type but the pivot table would still have the same problem of storing foreign keys in the same spot for mult开发者_Go百科iple tables.

Maybe I could simply store different types of transactions in different tables entirely, I could have:

user_accounting_deposit, user_accounting_credit, user_accounting_transfer, user_accounting_purchase.

And then the foreign keys wouldn't be a problem. Of course to figure out anyones account balance I'd have to do joins and sums from a bunch of tables now.

Perhaps there's an entirely different better way of doing it. I don't care how many tables it takes. Chances are I'm over complicating something somewhere.

Thanks

Bookkeepers have been dealing with storing where the money is coming from and where the money is going for over 500 years. That's why they invented double entry bookkeeping. Otherwise known as double entry accounting.

You need to take a look at a data model for double entry bookkeepiing. This has been done thousands of times by programmers who came before you.

If you need a sample model, visit Database Answers and look under "Accounting Systems". You should be able to get a model diagram that covers your case.