nelsonm - 3:55 am on Jan 21, 2012 (gmt 0)

After reviewing mark_rouch's post and rocknbil's suggested links, it appears that there is nothing wrong with using one table where each service item/price record also contains its associated sub item/price. It seemed obvious since there was a one to one relationship between items and sub items. The only down side, it appears, is that it limits its capability to the present.

Separating them into two tables leaves the door open and makes it easier to employ future capabilities without drastically affecting the existing architecture and programming.

Would that be a fair assumption?