Question

The question is add more columns or split database table.

Assume that I have a table which keeps:

UserId - Primary Key
Col1
Col2
Col3

Now I will keep another data as Col4 Col5,
but this data won’t be valid for every UserId.

Let’s say there are 2 million records at my main table and this additional data will be valid for only 25000 records. So the question is: should I compose another table as

UserId - Primary Key
Col4
Col5

or

use my main table as

UserId - Primary Key
Col1
Col2
Col3
Col4
Col5

Which way I should go? I care about performance. These additional cols are tinyint and will be default 0 not null.

SQL server 2008 R2

Answer 1

You don’t say what your existing fields are. And also, there isn’t a datatype called ‘tinyBit’.

Even so, there are two possible impact cases:

1) Your table includes a bit column already and you are adding two bit columns

In this case, because bits are stored in packed bytes, the performance difference would be negligible anyway.

2) Your table doesn’t include a bit column, or you are adding tinyint columns

In this case, performance would be impacted – as there would be extra information per row. However, 2,000,000 records isn’t huge at all. A simple way to negate the cost of storing the extra columns in the same row would be to add an index which used INCLUDE to include the Col1, Col2 and Col3 columns. In that case, it would be usual for the Query Optimizer (QO) to select an index seek on the index with the included columns rather than a clustered index seek because it would have less cost.

Edit -> Given your clarification, case 2) applies, and creating an index with the relevant columns INCLUDED would likely increase performance over any existing clustered seek. There will be an insert cost – so it would be down to the table’s read/write balance as to whether it was worth it.