Vinay Kannan wrote:
Currently the DB structure stores the following : 1) Customer details. 2)
Membership ID and the payment paid at the time of signing up (I am thinking
i might not need the signing up amount to be stored in the customer DB in
the first place, and have them seperate in a table called signinupfeespaid
or something like) 3) And maybe have another table called
'memberfeesintervals) which will have (membershipid,
paymentinterval,nextdueon) and then pick up the pending fees (Customer can
also issue part payments) from a pendingfees table

Any suggestion is welcome! Thank You in advance!

Personally I'd have a table for payments received since you will have many payments per MembershipId over time, but I'd probably keep the 'nextdue' and 'period' fields as part of a single customer detail table. There should only be one answer for 'nextdue' based on the last payment which will show the period paid for, and even this is a little redundant since it is available from the last payment record, but I see no need for a third table? Just set the right 'relations' between the master record and payment list?

Lester Caine - G8HFL
Contact -
L.S.Caine Electronic Services -
EnquirySolve -
Model Engineers Digital Workshop -
Rainbow Digital Media -

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to