Search code examples
sql-serversql-server-2008database-designdatabase-normalization

SQL Server: Many columns in a table vs Fewer columns in two tables


I have a database table (called Fields) which has about 35 columns. 11 of them always contains the same constant values for about every 300.000 rows - and act as metadata.

The down side of this structure is that, when i need to update those 11 columns values, i need to go and update all 300.000 rows.

I could move all the common data in a different table, and update it only one time, in one place, instead of 300.000 places.

However, if i do it like this, when i display the fields, i need to create INNER JOIN's between the two tables, which i know makes the SELECT statement slower.

I must say that updating the columns occurs more rarely than reading (displaying) the data.

How you suggest that i should store the data in database to obtain the best performances?


Solution

  • I could move all the common data in a different table, and update it only one time, in one place, instead of 300.000 places.

    I.e. sane database design and standad normalization.

    This is not about "many empty fields", it is brutally about tons of redundant data. Constants you should have isolated. Separate table. This may also make things faster - it allows the database to use memory more efficient because your database is a lot smaller.