in reply to Database Design Issues - OT

First off I don't think this is off topic at all. Consider that we all solve real world problems (normally for money) and we use Perl to make it more fun. Its this kind of thing that crops up all the time.

I hate to say it but I think that the only case for denormalisation comes once you have a fully normalised database - in other words at the end during the performance test phase. Not earlier.

Whenever I do any denormalisation, I tend to replicate IDs to simplify my joins to a smaller number tables (and have my code pull the IDs across) or I build a new table based on the type of data I am using (normally I use this just for reporting).

I have to agree with the other posts relating, mainly, to scalability. You don't know what will happen to the code and db once it leaves your grasp - but when it fails it will fall to you to fix it.

As an aside - I always build category <-> product relationships along the following:

CATEGORY
~~~~~~~~
ID
name
parent_ID


PRODUCT
~~~~~~~
ID
name
.....


PRODUCT_CATEGORY_LINK
~~~~~~~~~~~~~~~~~~~~~
category_ID
product_ID


What do you think? If you have a flat list of categories - all your 'parent_ID' entries will be 0 (default them to 0 in your DB design).

I'm not saying this is the best way to do it but when people have argue with me (during various projects) I have managed to argue this structure well enough to keep it :)

Good luck :)