DB design : save different details of payment (credit or check)

Question

I have a member that can pay in three different ways:

1. credit card
2. check
3. transfer from bank account

How can I design a table t

Answer 1

I think the wrong answer is to have 3 tables. Then the common data -- like "amount paid" -- is repeated across multiple tables, and a simple query like "what is the total that has been paid this month" requires a 3-table union or join. Plus if a fourth payment type gets added, any queries that worked on the 3 tables have to be modified, and someone will surely miss one.

So there are two possible right answers: a single table with some fields that are unused for some payment types; or 4 tables, a generic "payment" table with the common information and then 3 auxiliary tables with the information specific to each payment type.

Some people will say that you must create 4 tables for dogmatic reasons. Personally I'd be more practical: How much different data do you have? What queries will you be doing? I've had a few systems where I've let "account_number" be a bank account number for checks and a credit card number for credit cards and that hasn't gotten me into any obvious trouble, though I feel a little guilty about it.

When the number of data fields gets large, I tend to break it up just because it otherwise gets messy and confusing. Again, pragmatism: one unused field doesn't seem too ugly, but twenty unused fields definately is.