Question

We are designing a high volume SQL Server application that involves processing and reporting on data that is restricted within a specified year.

Using Partitioning by year comes to mind.

Another suggestion is to programmatically create separate physical table where the suffix of the name is the year and, when reporting is needed across years, to provide a view which is the union of the physical tables.

My gut tells me that this situation is what partitioning is design to handle. Are there any advantages to using the other approach?

Answer 1

From an internals perspective, the methods are essentially the same.

Behind the scenes, when you create a date-based partition the SQL engine creates separate physical tables for each partition, then does what is basically a UNION when you query the table itself.

If you use a filter in your query on the partitioned table that corresponds to your partitioning field (DateField let’s say), then the engine can go directly to the partition that you need for the data. If not, then it searches each physical table in the logical table as needed to complete the query.

If your queries will involve a date filter (which it sounds like they will from your question) then I can think of no advantage to your “custom” method.

Essentially, the choice you need to make is do you want to be responsible for all the logic and corner cases involved in partitioning, or trust the developers at Microsoft who have been doing this for decades to do it for you?

For my own purposes, if there is a built-in framework for something I want to do then I always try to use it. It is invariably faster, more stable, and less error-prone than a “roll-your-own” solution.