SQL Server (2005) table width (best practices and recommendations)

[Mr. Tomaszek]

Hi All,
I'm just wondering about what would be recommended width of a sql table (schema wise). By that I mean width calculated as

 select sum(max_length) from sys.columns where object_name(object_id) = 'MyTableName' and max_length > -1

The reason for my question is that I’m working upon recommendation from DBA department that no table should be wider than 1 KB. I got limited database development background, but according to my knowledge SQL Server 2005 should eat for a breakfast tables much wider that 1 KB. What also concerns me, as a person responsible for overall application design and delivery timeframes, that splitting one set of data between multiple tables (to stay compliance with 1 KB requirement) will increase the effort needed for development as I cannot re-use any existing tables/business layer objects.
Any comments on this would be greatly appreciated.
Thanks!

[dglienna]

Ask about 10,000 columns of the BIT data type. Should fit into 1K.

Then, tell him that's the silliest idea that I've seen from a PRO.

[Alsvha]

<snip>
Then, tell him that's the silliest idea that I've seen from a PRO.

I'll have a hard time assigning the term "pro" to somebody who would suggest such a thing

[Mr. Tomaszek]

Do you think it may be related to our DBA department dedication to keep db performance at a highest level?

I can agree to the argument that too wide tables might contribute to poor optimization of statements. But what does is mean "too wide". Or more importantly, what would be reasonable width of a table for SQL 2005 (assuming system with some legacy stuff in it).

[Alsvha]

I think it is either a misunderstood concept or a misinformed concept. My guess would be something like he's thinking it's more efficient to write to disk or similar, but that's a guess - because I can't recall seeing much about "limiting table width" so I can't judge the argument based on its own, without reasoning to back it up.
The very little you might gain from something as that, which I'm not even sure will be a factor, are IMO resources better spend on optimizing indexes, stored procedures, functions, the disk layout and all those things which do matter quite a lot.

Also remember, that the performance in the application also counts towards overall user performance, so if the code layer becomes significantly more complex or slow due to changes in the database, then the "gain" in one area can easily be lost in another. Something in my experience which many seem to forget.

And that's not even factoring in the increased development time and cost stemming from such decisions.

I've not read anything about "best practice" for table width, so naturally you should only use the size of fields which are needed, to limit the amount of data moving around the system, but worrying about table width seems .... academic at best. At least until I see something credible about it.

[Mr. Tomaszek]

Thanks very much!