Skip to content
Advertisement

What is more efficient, few small related tables or one big?

I have information about a Shop. It belongs, to a City. City belongs to the Country. And Country belongs to a Continent.

Should I make one big table that contains 4 columns with information about every Shop. Or should I make 4 tables. First with Continent column. Second with Country and it’s relation to a Continent. Third with a City and it’s relation to a Country. Finally fourth with a Shop and it’s relation to a City.

What is the best approach?

Advertisement

Answer

So, the usual approach to this would be to use separate tables linked with foreign keys.

Why? Well lets say you open 10 new shops. Sure you could just add their details to your shop table but the more shops you open and the harder placenames are to spell, the more likely it is that errors will creep in. Having a linked table means you have a single version of the truth. In other words you have Mississippi once, and no risk of also having Misissippi or Missisippi.

Not only that but in the one table approach you are storing country, city, continent using text. So if your shop inventory or sales get big and you want to generate a report by city or country, that query is going to get slow really quickly.

By having a seperate table with an integer primary key, SQL can search really fast for sales in that city, or country. Not only that but it’s easier to create reports such as all sales by shop for City x or Country x.

User contributions licensed under: CC BY-SA
4 People found this is helpful
Advertisement