Database Structure Advice Needed

Question

Im currently working on a site which will contain a products catalog. I am a little new to database design so I\'m looking for advice on how best to do this. I am familiar wit

Answer 1

My suggestions

• put a many-to-many relation between Item and Category so that a product can be displayed in many hierarchy node (used in ebay, sourceforge ...)
• keep the category hierarchy

Performance on the category hierarchy

If your category hierarchy is depth, then you could generate an "Ancestors" table. This table will be generated by a batch work and will contains :

• ChildId (the id of a category)
• AncestorId (the id of its parent, grand parent ... all ancestors category)

It means that if you have 3 categories : 1-Propeller > 2-aircraft > 3-wood

Then the Ancestor table will contain :

ChildId  AncestorId
1        2
1        3
2        3

This means that to have all the children of category1, you just need 1 query and you don't have do nested query. By the way this would work not matter what is the depth of you category hierarchy.

Thanks to this table, you will need only 1 join to query against a category (with its childrens).

If you need help on how to create the Ancestor table, just let me know.

Answer 2

Before you create a hierarchical category model in your database, take a look at this article which explains the problems and the solution (using nested sets).

To summarize, using a simple parent_category_id doesn't scale very well and you'll have a hard time writing performant SQL queries. The answer is to use nested sets which make you visualize your many-to-many category model as sets which are nested inside other sets.

It should be worth pointing out that the "multiple categories" idea is basically how "tagging" works. With the exception that, in "tagging", we allow any product to have many categories. By allowing any product to be in many categories, you allow the customer the full ability to filter their search by starting where they believe they need to start. It could be clicking on "airplanes", then "wood", then "turbojet engine" (or whatever). Or they could start their search with Wood, and get the same result.

This will give you the greatest flexibility, and the customer will enjoy a better UX, yet still allow you to maintain the hierarchy structure. So, while the quoted answer suggests letting categories be M:N to categories, my suggestion is to allow products to have M:N categories instead.

All in all the result is mostly the same, the categories will have a natural hierarchy, but this will lend to even greater flexibility.

I should also note that this doesn't prevent strict hierarchy either. You could much easily enforce hierarchy in the code where necessary (ex. only showing the categories "cars", "airplanes", and "boats" on your initial page). It just moves the "strctness" to your business logic, which might make it better in the long run.

EDIT: I just realized that you vaguly mentioned this in your answer. I actually didn't notice it, but I think this is along the lines you would want to do instead. Otherwise you are mixing two hierarchy systems into your program without much benefit.