>I need some "sound" advise on properly designing my tables and/or classes. I need to design an app that handles working with publishers (e.g. newspaper, magazine, radio, TV, etc.) with different cost calculations. For example, newspapers may charge by rate/inch, magazine by size, flyers by quantity, radio by duration and frequency, etc.). My question is:
>
>1. Is the best approach to designing the database is to create a different child cost tables for each different cost types in the parent table?
>2. How can I make it flexible enough to minimize modification time when another type of cost needs to be added?
>3. Finally, if I were to create custom VFP classes based on the above requirement, how would I design and implement this? Great example would be data entry screen. Would I create a generic data entry screen and subclass it for each different type of cost depending upon the cost type of each publisher?
>
>Some even have variation on the basic cost. Example: qty mailed for different zipcodes needs to be entered separately but are combined if in the same mailing to compare against the "cost by qty" lookup.
>
>Any though on this subject would be greatly appreciated.


I would not have a separate child table for each cost type. I would have 1 Costs table with fields for a KeyID, Description, CostPerUnit, etc. I think you could even design it to accommodate the ZipCode distance variable rate.

For certain I would have a custom class where I pass the Costs keyid and other pertinent parameters to in return for a cost.

When I am asked to do something like this, I just use an inventory/invoicing type analogy when designing the tables. If you have the luxury of being around other developers, it might help to sit around a table with pencil and paper and diagram exactly what your data needs are. You could still do this, if you are the only one available.

Don't know that you really need an extensive custom class just for this. If you already have a framework that you like, use a copy of it and make changes or additions as needed.