I am designing a product database and I have a design question.
There are several different categories of products, say books, video games, home electronics, and pet supplies. There are some things in common, say the manufacturer, and price, while other things are unique to each category, say power consumption.
The individual products will be updated periodically, the price could be volatile, while the manufacturer will remain fairly constant (I suppose a manufacturer could be bought by another company and the brand name absorbed into the purchasing company). Updates could happen on an hourly basis. Requests for each product could be made frequently (depends on the number of clients, so unbounded).
I am much more concerned with the speed of accessing the data for the clients than I am for the speed at which I cam perform updates to the data.
Which makes more sense and why?:
- one table for all categories with columns allowed to be null (for example pet supplies would have null for the power consumption)
- one table for each category with columns repeated (for example price would be in each table)
- one table for the common features (price, manufacturer, etc…), and one table for the unique properties
I’d say one table for the common features, and another with unique properties.
You could simulate something like the decorator pattern, where the extra properties are just tags associated with the products.
You will probably want groupings of tags, to make it easier to add new products.
With the above configuration, you’d probably find it easier to expand with new tags, and adding/removing tags as classifications change.
I could see the following issues with the other approaches.
If everything was in one table you’d have to know everything up front and constantly change the table as new field were thought up and leave many fields as NULL.
With the table per category, you’d end up having to create many different queries for each type of product and moving forward, it might get hard to maintain.