I'm building an application that users can pay some fees to sign up for a yearly membership and courses they're interested in.
Currently, I'm planning to have two different tables: 'course_payment' and 'membership_payment'. The reason behind this is that they have very different fields although they share some same information.
For example, course_payment table will have course title, regular price, special price, # of accompanying guests, guest price... and etc. membership_payment table will have the name of membership, membership start date and expiry date, and etc...
Well, they have some common fields such as user_id(payer), subtotal, tax, tax_type and total. However, normalizing tables for payment transaction history seems a bit too much and cumbersome unless there's a very good reason for it.
Do you think I should have two different payment history tables for each? If storing them all in one table is a better approach, what should I do with all the info that are only needed for one or the other such as course name and membership name?