Tsql 按年份划分与命名为Data_2011、Data_2010等的单独表划分

我们正在设计一个大容量SQL Server应用程序，该应用程序涉及处理和报告限制在指定年份内的数据

我想到了按年份使用分区

另一个建议是以编程方式创建单独的物理表，其中名称的后缀是年份，当需要跨年份进行报告时，提供一个视图，该视图是物理表的并集

---

我的直觉告诉我，这种情况正是分区设计要处理的。使用另一种方法有什么好处吗？

我觉得使用带有日期驱动的分区键的分区就像使用锤子拧螺丝一样…“这一定是他们发明锤子的原因”…当您需要像在数据集市中一样运行并行进程或在某些任意键上分区时，分区是很好的，例如标识列。在您的情况下，业务需求只是保持多年的历史。为了使用分区，应用程序团队需要创建一个例程来动态生成分区约束，即DDL，这是DBA团队的责任。multi-table/union视图提供了一个简单得多的解决方案。

这两种解决方案都意味着您必须在数据库中执行一些元数据操作。问题是您是否会对历史数据进行一些更改/更新？我正在研究类似的解决方案——bud，而不是一年，而是半年的数据。在本例中，我们使用了按日期划分的分区—我们有半年浮动窗口，在10个分区中保存2年的历史数据+当前半年（HTD）（每个分区代表一个单独的季度）。我们每天更新HTD数据，每周更新一次历史数据。在本例中，我们只访问了几个分区（分区id是在where子句中定义的，分区键是一个date_id，表示我们的一个维度中的日历日期）。整张桌子大约有250米长的行。每半年，该过程都会调整分区，但您也必须对视图进行同样的调整。使用这种方法，我们总是可以对整个表执行更新（使用视图，您必须测试更新场景或对单独的表运行更新）。我们有适当的过程，可以截断/切换出表的指定分区，因此操作很快

---

很难说哪一个是最好的选择。但一般来说，我建议在您确实没有更改历史记录的情况下使用这些表（我选择1个分区表作为历史记录，1个分区表作为当前数据）

从内部角度来看，这些方法基本相同。

在幕后，当您创建基于日期的分区时，SQL引擎会为每个分区创建单独的物理表，然后在查询表本身时执行基本上是

联合的操作

如果在对分区表的查询中使用与分区字段（
DateField
）对应的过滤器，那么引擎可以直接转到数据所需的分区。如果没有，则根据需要搜索逻辑表中的每个物理表以完成查询

如果您的查询将涉及一个日期过滤器（听起来好像他们会从您的问题），那么我认为您的“自定义”方法没有任何优势

本质上，您需要做的选择是您是想对分区中涉及的所有逻辑和关键案例负责，还是相信Microsoft的开发人员几十年来一直为您这样做？

出于我自己的目的，如果我想做的事情有一个内置的框架，那么我总是尝试使用它。它总是比“滚动您自己的”解决方案更快、更稳定、更不容易出错。
我唯一推荐后一种方法的时候是，如果您不在Enterprise Edition上（您不能在Standard等上使用分区）。Aaron是对的。分区基本上是幕后的第二种方法，但服务器引擎为您处理所有逻辑。不要创建sock puppet帐户，然后用它们更新主帐户。我正在删除Velika2并重新计算您的声誉。如果使用分区方法，我认为必须使用动态SQL，因为必须动态构造表名（将当前年份添加到名称后缀中），除非当前年份始终存储在无后缀的表中。所有这些手动使用名称的操作，虽然没有那么复杂，但只是增加了手动维护，使分区方法看起来更合适。我看不出为什么按日期划分（如一个答案中所解释的）是不恰当的。在我看来，这个场景似乎是分区的理想选择。@Chad-分区的唯一好处是与维护相关的-更容易交换数据集等等。如果只是每年一次的活动，这可能不值得。@JNK-唯一的好处是与维护无关。如果您使用的是企业版（|可扩展性和性能->分区表并行），那么查询计划器应该降低查询成本（），而不进行分区。您必须根据搜索的日期范围为该实体生成查询。它只会为该实体生成大量联合，如果您想与其他表连接，则查询会变得更大、更重，并且应该为所有情况动态生成。从维护的角度来看，在执行插入时，您必须自己在正确的表中定位数据，您必须检查与其他表的引用完整性，重复约束。。。您只需使用一个分区表即可完成所有操作。