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 - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
