Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


DB Design for Product and Subproduct Tables

Posted on 2007-12-06
Medium Priority
Last Modified: 2008-02-01
We have a database which holds a list of products in a Product table. Each product can contain one or more subproducts, each of which is characterised by a product type. This is how I was thinking of designing the relevant tables:

- Subproduct Type Table (PK Subproduct Type ID, Subproduct Type description);
- Product Table (PK Product ID, Product attributes) has a one to many relationship with
- Subproduct Table (PK Subproduct ID, FK Product ID, FK Subproduct Type ID, Subproduct attributes).

However, someone has suggested to me the following design, which apparently should help queries to run faster:

- Product Table (PK Product ID, Product attributes) has a one to many relationship with
- Subproduct Type Table (PK Subproduct Type ID, FK Product ID, Subproduct Type description) has a one to many relationship with
- Subproduct Table (PK Subproduct ID, FK Subproduct Type ID, Subproduct attributes).

Which design would you recommend? I have worked with databases before, but I have never designed one from scratch.
Question by:Rothbard
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
LVL 25

Expert Comment

ID: 20418391
It really depends on what sort of typical queries you expect to run in the future, as well as whether the relationship makes sense at all!
LVL 25

Expert Comment

ID: 20418408
Your original design allows for

Product: Car, Truck, Van, Bike  (vehicle)
SubProduct: LightVan, Tricycle, ForkliftTruck
SubProductType: Budget, MidRange, Premium.

So you can Budget-car, budget-van, premium-bike etc, with SubProduct in the middle.

However the suggested design swaps this all around.

Product: Car, Truck, Van, Bike  (vehicle)
SubProductType: PremiumCar, BudgetCar, LightBike, CompactCar, PremiumVan
SubProduct: etc etc

You see how the relationships are completely different. It makes a lot less sense to change your design, unless you have 10million records and 2000 product types and a slow database engine.  Then maybe the 2nd design can serve the query "Budget cars" a little faster, but not even by much.

Author Comment

ID: 20418591
Sorry, I should have clarified what I meant. The relationship between Product and Subproduct is a "has a" one. A better description would have been "Product" and "Component". Each Product is made up by 1 to 5 Components. We have tens of thousands of Products and Components. In total there are only about 10 different Component Types.

If we choose the first design, we are going to have a very small Component Type table, with 10 different entries listing all the Component Types in the system. The Component table is linked to the Product table by a Product ID foreign key, and to the Component Type table by a Component Type ID foreign key.

If we choose the second design, the Component Type table will have a separate entry for each Product, i.e. it will have Product ID as a foreign key. The Component table then has only got a Component Type ID foreign key.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

LVL 25

Expert Comment

ID: 20418702
I did understand that.  I was just illustrating that they have very different meanings.  Your "small items" category has to be replicated for each Product in the 2nd scenario.

Author Comment

ID: 20418782
So you would recommend the first scenario?
LVL 25

Accepted Solution

imitchie earned 2000 total points
ID: 20418874
For me personally, yes, it makes a lot more sense relationally.
But as with all things, only you would know best. What works 90% of the time may just not work if you fall into the 10% category.
If you had good indexes on the foreign keys on Component, I can't see why it should be much slower, if any.

Author Comment

ID: 20530606
Sorry for the delay, I had forgotten to accept your answer. Thanks.

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this series, we will discuss common questions received as a database Solutions Engineer at Percona. In this role, we speak with a wide array of MySQL and MongoDB users responsible for both extremely large and complex environments to smaller singl…
This article shows how to get a list of available printers for display in a drop-down list, and then to use the selected printer to print an Access report or a Word document filled with Access data, using different syntax as needed for working with …
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…
This lesson discusses how to use a Mainform + Subforms in Microsoft Access to find and enter data for payments on orders. The sample data comes from a custom shop that builds and sells movable storage structures that are delivered to your property. …
Suggested Courses

618 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question