Hi. It's not an uncommon problem, but there are hundreds of possible solutions. The main issue is what will the user interface be? How will the complexities of defining these relationships be presented to the user? How can the user interface be simplified to aid in adding/ updating items? How will the user be able to understand what the effect of changing something will have (e.g. exactly which items will be affected by a change)? Once the user interface is defined, the database structure that will most easily support this (and help ensure data integrity) will be much more apparent. -Craig
On Jul 16, 8:06 am, Peter S <[email protected]> wrote: > The flexibility to customise unique formulas, and yet maintain the > formula_components extensively and uniformly. In this case the tension is > between allowing each treatment to have a sufficiently customised formula, > and yet be able to maintain large groups of treatment formulas over time as > the components or formulas change. Im not sure if this is terribly > coherrent, but i guess if youve ever been faced by this quandary it will > make sense. > Peter --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
