Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
sjohnson4532
Starting Member
4 Posts |
 Posted - 2012-01-13 : 18:28:42
|
| I am considering partitioning tables based on the values of the auto-increment fields that exist. This is a large database that has hundreds of stored procedures. I would be dynamicly altering my partitioning function monthly. I am new to partitioning and was wondering if there is anything wrong with this design? Any help is much appreciated. |
|
|
visakh16
Very Important crosS Applying yaK Herder
52326 Posts |
Posted - 2012-01-14 : 01:00:34
|
| why should you be changing partition function? cant you preplan on what range you want records to be split into partitions?------------------------------------------------------------------------------------------------------SQL Server MVPhttp://visakhm.blogspot.com/ |
 |
|
|
Bustaz Kool
Master Smack Fu Yak Hacker
1834 Posts |
Posted - 2012-01-17 : 19:25:37
|
| We had a hospital medical application that partitioned the data by date and ran a daily job that updated the partitions. This sounds similar to what you are envisioning. This worked for us because the vast majority of the queries run against the data were relative to the current datetime. When we ran a query to return the data from the last 24 hours, only the last two partitions would be searched. If your queries are not using your auto-increment column as part of the filtering (e.g., WHERE clause) I wouldn't expect partitioning to be of much use to you. Your partitioning column(s) needs to be a part of your query; otherwise, how would the SQL Engine know which partitions it can omit?My question to you is, how would the auto-increment column be a part of your queries?=================================================Men shout to avoid listening to one another. -Miguel de Unamuno |
|
|
|
|
|
|
Partitioning Question