Question

We have multiple category hierarchies where the categories can be nested N-levels deeps and we have products that can belong to multiple categories in multiple hierarchies. My co-worker and I are disagreeing on what the best table structure is.

His structure is:

Nodes
---------------------------
NodeId (identity)
ParentNodeId (nullable)
ProductId (nullable)
Description (this is the category or product description)

My structure is:

Categories
-----------------------------
CategoryId
ParentCategoryId (nullable)
Description

ProductCategories
-----------------
CategoryId
ProductId

Both would assume there is a products table too

Products
-------------------
ProductId
ProductDescription
UnitPrice
etc...

So basically, he tracks what products are in each category by adding another record in the Nodes table, whereas I would create a new record in the ProductCategories table. He says that his way is better for performance and that it's the recommended way by Microsoft. Can anyone verify this? Are there any performance or maintenance concerns that would allow us to choose one over the other? There are hundreds of categories and tens of thousands of products.

Thanks.

Was it helpful?

Solution

I would personally select your structure for the following reasons:

  1. It's more normalised and shows the intention of design better. It will be easier to understand for new people.
  2. It's better for future extension as categories and products are kept separately and are not mixed together. You may avoid adding nullable fields that are only for products or categories.
  3. His design has more nullable fields which may (not necessarily though) impact on performance, e.g. when selecting all products belonging to a category. Building a tree of categories will also be easier as you won't have to check for products.
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top