Thank you yes, this is what I am asking about.

Speed wise is it not adding too many layers to have the
Product_General table in there? That is a whole new table and indexes.
Would it not be simpler (and faster) to just add the Prod_type field
to the PurchasedProduct table? What advantages does that extra layer
give you? Is it just flexibility, because I don't need that. Not if
it's going to slow queries down a bit.


On Mar 14, 2:31 pm, Erick T. Barkhuis <erick.use-...@ardane.c-o-m>
wrote:
> rtconner:
>
> > Ok so lets say I have several types of purchasable commodities &
> > services - Products, Services, Packages (products & services grouped
> > together), and Other (unkown fees and such that need to be accounted
> > for)
>
> > So normally.. products, services, packages, and other all get their
> > own table.
>
> > On a purchase though I have to store what commodities have been
> > bought. Currently this means I have resource_id (the product, service,
> > etc primary key) and then resource_type (enum to point to table
> > holding commodity)
>
> I assume, you want something like this:http://ardane.com/demo/ProdPurch.png
>
> You have products, which have generic data, and specific data for each
> type of product. The generic data are stored in entity Product_General
> and the specific attributes in ProdA_specific.....ProdX_specific.
>
> The relationships to Purchases, Invoices (etc) all go through
> Product_General. This way, you have the flexibility to add and remove
> products and to introduce new entities like "Tax doc", "Packing slip",
> etc.
>
> --
> Erick