I currently have a web site hitting 7 Access DBs that I desperately need to move to SQL Server. The 7 db design is screaming fast, but obviously very poor for a number of reasons.
In the 7 dbs I have collectively over 375 unique fields of data virtually all of which are populated – less than 2% are nulls. Short of a few keys, there is no duplication of data across the 7 so normalization is probably not an issue. I wanted to keep the tables small so it would be fast. The 7 tables all have the identical number of records which is 325,000 and will max out around 400,000.
When moving this to SQL Server should I keep the 7 unique tables or combine into 1? My understanding (limited as it is) was that I would need to be very disciplined in my stored procedures to only bring back the columns I need. Given the huge variety of similar questions I still never came across a “consensus” on the best approach.
Thanks.
That depends on your access patterns. Do you often need to access data from multiple partitions at once? Then you should probably combine them.
Anyway, development is probably easier when you only have one table (without one-to-one joins). If there is no particular reason to split them, combine them.
Attention: I think there is a column limit in SQL Server.
You can expose subsets of the columns by creating indexes. Each index would be set on the ID column with an arbitrary subset of columns as “included” columns. This will leave the choice to the optimizer. It will choose the best possible way. It can also join between indexes so you are in a total win situation that way.
Recommendation: Combine the tables into one and create one index for each table you previously had.