I have a simple database ordering system at the moment. I am currently implementing the payment side of things. As we generally collect full payment I don't need to worry too much about multiple invoices etc.

Basically we accept payment via Credit Card, Cheque or Cash. If our customer pays via credit card we obviously have to store card details. If they pay by cheque we store cheque number and bank details. If they pay by cash then don't really need to store anything. I have a payment method field with these three options (Cash/Cheque/Credit Card).

My question is this. If my customer chooses to pay by cheque then it seems a waste of space to have all the credit card fields. And if they pay by credit card the same goes for cheque # and bank details.

If there a table structure (I know a little about schemas so I'd be an intermediate user) that would suit this situation?

To answer my own question (my best guess would be):

Create a layout that included portals to different tables for each payment type. ie. 'Credit Card Payment' table would join via Order ID. Same again for 'Cheque Payment'. That way if I don't enter any data then I'm not using blank fields that I don't need. Hope this makes sense.

Any comments would be appreciated.

Cheers, Chris.

Create a layout that included portals to different tables for each payment type. ie. 'Credit Card Payment' table would join via Order ID. Same again for 'Cheque Payment'. That way if I don't enter any data then I'm not using blank fields that I don't need.

...but then you've got 3 big portals on your layout, so I don't think that's going to conserve any space! Why not just a single portal to a payments database, where you select a payment method, enter an amount, and enter additional information into cardNumber, cardExpiry, cardAuth, and chequeNumber. Why is it a problem if some of these fields go unused?

Just repeat "they aren't really there, they aren't really there" over and over again .

(a couple of empty field really don't use any space to speak of)

-bd