Question

I have a SQL Mobile database with one table. It has several columns with useful, often queried data and one column that stores a relatively large string per record (1000+ characters) that is not queried often.

Imagine this fake schema, the ‘lifeStory’ field is the large one.

table1 String firstName String lastName String address String lifeStory 

A representative query would be

SELECT firstName, lastName, address FROM table1 WHERE firstName = :p1 

Does anyone know of any performance concerns leaving that large, infrequently queried column in this table?

Answer 1

Using VS2005 (c#) and SQLServerCE libriaries I can tell you that it does affect performance but I cannot truly answer why. Furthermore, it’s actually the length of the data in that column that negatively impacts performance rather than the column itself.

Doing some performance testing of my own on a project for work I ran into a similar scenario just one extra column.

table1  c1 NVARCHAR (20) c2 NVARCHAR (20) c3 NVARCHAR (20) c4 NVARCHAR (20)  c5 NVARCHAR (4000) //maximum allowed and fully populated for testing purposes 

If you run…

select c1, c2, c3, c4 From table1 

…it takes roughly 1560 milliseconds.

If you create two tables, pulling the large column out (and providing a foreign key to relate the two, naturally) and run the same query on the first table, it takes roughly 660 milliseconds.

Lastly, other tests have shown me that it’s not the number of columns but rather the size of the data in each row. i.e. 5 columns, 2 chars wide == 2 columns, 5 chars wide. Also, be sure to run these on your mobile device. You can unit test these but due to the significantly greater horsepower on my PC I found the timing difference to be 10-20 milliseconds rather than the nearly 1000 milliseconds illustrated above.

Why? This is just a guess but…

In the mobile world the DBMS just can’t be the same; it’s not an enterprise database. Under the covers I bet they are still performing the OLEDB ‘seeks.’

Overall, in the mobile space I’ve learned design my DB’s not to be the most ‘normalized’ but rather to support the most frequent use case. Good luck!