So, I am creating a transaction database table to store, well, transactions between the merchant and customer.
Sometimes the customer will pay with a store card and other times with a credit card (cash is not used in this system).
How do I model this in the database. My current thinking is that the transaction table has a field for store card transaction and one for credit card transaction. These fields will then reference two seperate tables to store data specific to the payment method.
This means that one of these fields will always be null while the other is a reference to the appropriate payment method table.
Example:
A transaction was completed with a credit card and not a store card. This means that in the transaction table, the store card field is null, while the credit card field contains a reference to the credit card transaction table. This credit card transaction table stores data related to a credit card transaction e.g. auth code, transaction id etc.
The reason this has me confused is because I was taught in college that NULL values are bad. But is this not a case where they are required.
Is there a term for this type of problem or what query should I be using to match it in Google?
Many thanks, Conor.
Do not use two card number fields
CardNumber should be one column and contain any card number from any transaction. You should have another table somewhere on the system that keeps track of which “Store Cards” have been issued. A join from the transaction table to the “Store Card” table will identify which transactions were made using store cards and which ones were made using credit cards.