Morning All,Regarding a partitioned table -- does it ever make sense to have the index partitioned on something else, or is it considered a best practice to align it.I ask for the following reason:I have a table, it has a few million rows in it, nothing spectacular -- but there is a blob in there. The table itself is 500GB.EDIT: The table is 2.3TB not 500GB. I am not sure how I wrote that.It has a legacy app pointing at it which we cannot change. As usual.Currently the table is not partitioned but it is heavily indexed.At some point in the middle distance is the idea to archive some old data out but that isn't here yet.The table is most often queried on UserID and CategoryID (both int/bigint).The table contains two date fields CreateDate an UpdateDate -- as far as I can see UpdateDate is mostly null and I'll ignore it for now as its RARELY gets updated. In fact out of the few million rows only 2 have ever been updated 6 years ago.Part of me wants to partition on CreateDate because it makes Archiving data out much easier. I can just remove the partition pertaining to 2011.However, another part of me thinks partitioning on CategoryID (there are a finite number, 143 to be exact, these arn't likely to be added to anytime soon and if so, at most 2 rows). Would be better for performance. And performance is the main point here.Is it possible to partition an index so differently to the table? Is it wise?Does anyone see a problem with my thoughts?Cheers All,AlexGiven that does it make sense to Partition on CreateDate
↧