Generally speaking, I think the answer is yes, but there are never simple answers ...
Access to columns within a row is pretty efficient. Fixed width columns are stored as offsets within the row; it doesn't take any longer to access bytes at offset 5312 than it does at offset 0. Variable length columns are stored a little differently, with an extra level of indirection, so access to them is generally a bit slower, no matter how many of them there are or where they are located.
The more columns there are in a row, the bigger the row is. This would mean that fewer rows would fit in a page, so more pages would be required to store the data, which means more page seeks would be required to satisfy any given query.
But this also holds true if there are just a lot of rows in a table, or if the few columns are very "fat" - there'll be more pages that way too.
I think you would be far better off worrying about whether your table structure is correctly modeling the entities it is supposed to represent. A poor table design will result in queries that will take far, far longer to execute than any miniscule advantage you might realize by having a table with 47 columns rather than 147. If 147 is what it takes to model your application data requirements, then that should be the number of columns in your table. Splitting up the table into arbitrary pieces because of some perceived performance improvement is really the wrong way to look at it. A requirement will inevitably pop up down the road which will require you to join those rows back together, and that JOIN operation, run once, will wipe out years' worth of the millisecond improvements you got by reducing the number of columns in a row to something less than the application data requirements demand.
IMO :D
Jeff Mason
Custom Apps, Inc.
www.custom-apps.com
Seek Time...
