Results 1 to 3 of 3
  1. #1
    Join Date
    Aug 2016

    Payment history for two different things


    I'm building an application that users can pay some fees to sign up for a yearly membership and courses they're interested in. Should I 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? Normalizing the payment history table seems too much since these info will not be joined with any other info...


  2. #2
    Join Date
    May 2016
    Hi Pluus
    could you upload your logical data model even better conceptual data model?

  3. #3
    Join Date
    Nov 2004
    out on a limb
    different payment history tables no
    if you need to allocate payments to specific items then pick up the PK of those items as part of the payments row. thats no different to the commercial world where you (may) allocate payments to specific invoices so you have a clear idea of what has been settled and by inference what hasn't.

    but a payment is a payment, irresepective of whether its a payment for a course or membership.

    what I have done int he past ofr a club is create a notional invoice with product codes (2016Memb, 2016swim, 2016firstaid etc) then when you recieve the payment you know clearly what courses they still owe. if say all your courses are 25, they attend / book for 4 but pay 75 you know whcih course they haven't paid for
    I'd rather be riding on the Tiger 800 or the Norton

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts