In a discussion with Scott about the “text in row” option for LOB (Large Object Data types: text, ntext, and image) data he questioned whether or not it was really a good idea to set… Well, I have mixed feelings about it really. In general I don’t recommend it unless EVERY query tends to want the LOB data and if the LOB data is in general – narrow (meaning very few bytes). Yes, you do skip the extra lookup into the text/image b-tree but you also make all of the rows wider. If you don’t want the text info most of the time (i.e. the description is only needed when they [occassionally] click on that button for the request, etc.) then you’re putting all of those descriptions into memory when you don’t really need to. It’s [potentially] a great way to waste a large percentage of your cache.

 

So – I’d say that there really isn’t a byte limit more than a usage rule. BUT – if you do want to skip that lookup (because most of the time you DO want to return the description) then I’d start to look at the data and see what the “average” byte length is. If most of the descriptions are small but they want to use the text datatype for the very rare and very large description then this is a GREAT feature to keep the small (and very frequently accessed descriptions) with the data row and avoid the lookups!

 

(fyi – the b-tree index is just like any other; it’s the “index” associated with the table (object_id(‘tablename’) = id) and has an indid of 255 in sysindexes. Each table has only ONE btree for all LOB columns of that table and seeing the indexes, statistics, etc. that each table has is interesting if you ever look at the system tables.)