Question

I am redesigning a few databases into one encompassing database, and I have noticed the previous designer(s) of the old databases like to store categories in their own tables. For example, say that there is a table boats(bid: integer, bname: string, color: integer), and in the application there is a drop-down box allowing the user to specify the colour of the boat, then there is a table color(cid: integer, cname: string). I would have not included the color table, and just put the colours as strings in the boats table. I realize that this decreases redundant storage of colour names, but is the added run-time cost of joining the boat table with the colour table “worth it”? Also the drop-downs are populated with SELECT cname FROM color statements, while I would have defined a view on SELECT DISTINCT color FROM boats to populate the drop-downs.

The example is simple, but this happens multiple times in the system I am redesigning, even for categories with only two options. This has resulted in many tables with only 2 fields. Some only have 1 field (I haven’t figured out what those are for yet, but I think they are only to populate the drop-downs, and the actual tables contain the values as well).

Answer 1

I would personally keep them in their own table if this were my DB.

If you get into a situation where you get the requirement that Boats a,b and c can only come in silver and black then you will be thankful that you did. I’ve seen these types of requests bubble up down the road in a lot of projects.

If you are just concerned about the query complexity you could create a view that joins the information you need so you only need to query it once and with no JOIN.

If you are worried about the performance implications of the JOIN then I would look at creating the appropriate indexes or possibly an indexed view.

Good luck!