Tell me more ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.
up vote 1 down vote favorite

When I work on a huge database, and after following normalization rules, I found that I have many tables for each part of my huge database. That makes me worry about the final number of tables, it will be in the hundreds.

What is the best choice for me?

  • make many tables with a small number of columns? or
  • make few tables with many columns?
share|improve this question
1  
Please try and be more precise. What is "huge" 100M, 100G, 100T? Thousands or rows, millions, billions? What is "many many columns"? Your question would be better if you had an actual example problem of a (set of) tables, expected volume and growth, and the two options you're looking at in terms of "one wide table" versus "many narrow ones". – Mat Nov 1 '12 at 7:50

1 Answer

up vote 4 down vote accepted

In general, the more tables in a database, the more normalised it is.

If your table has many columns, the chances are that some of them will be empty a lot of the time, or repeating types, or other breaches of normalisation, so as you've discovered, normalisation leads to more tables. This is perfectly normal (no pun intended), is nothing to worry about and will lead to easier and more efficient querying

share|improve this answer
I will also point out that wider tables can have slower performance (at least in SQL Server due to how they get physically stored) and that you can run up on the record size limit in some databases if you make the tables too wide. – HLGEM Nov 1 '12 at 20:31
Oh and we have databases with around 1000 tables, it isn't uncommon in Enterprise applications. – HLGEM Nov 1 '12 at 20:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.