用于插入高读取表（Sql Server）的数据库策略

Question

寻找具有为报告和历史目的而维护数据的非常大型表的策略，在日常操作中使用该数据的一小部分。

背景：

我们有不断由我们直接面对消费者的网站更新游客和访问表。这些表格包含每个访问和访问者的信息，包括机器人和爬虫，不会导致转换的直接流量等。

我们的后端站点允许从前端站点管理访问者（主管）。大部分管理都发生在我们访问者的一小部分（访客成为潜在客户）上。访问者和访问表中的绝大多数数据仅保留用户活动的一小部分（基本上是报告类型功能）。这不是一个索引问题，我们已经尽了我们所能做的索引，并且保持我们的索引干净，小而不碎。

ps：我们目前没有数据仓库的预算或专业知识。

问题：

愿我们的系统时，他们查询，例如，分配给他们的潜在客户名单，以更加适应我们的最终用户。目前，查询是针对大多数不相关数据的庞大数据集。

我在思考一些想法。其中一个涉及新表和一个相当重要的重新架构，我并不是要求帮助。另一个涉及创建冗余数据（例如Visitor_Archive和Visitor_Small表），其中存在用于插入和历史/报告的较大的访问者和访问表，存在用于管理潜在客户的较小visitor1表，用于发送电子邮件的引导者，需要引导电话号，需要我的引线的名单等。

我伸手的原因是，我喜欢上保持Visitor_Archive和同步的Visitor_Small表的最佳途径意见...

复制？我可以使用复制来只复制具有特定列值的数据吗（FooID = x）

是否有其他策略？

Answer 1

这听起来像是你的桌子是分区的完美人选。既然你没有提到它，我会简单地描述它，并给你一些链接，以防你不知道它。

您可以跨多个物理或逻辑设备划分表/索引的行，专门用于提高数据集的性能，您可能随时需要知道数据的已知子集。对表进行分区仍然允许您将其作为一个表进行交互（您不需要引用分区或查询中的任何内容），但SQL Server能够对仅涉及数据的一个分区的查询执行若干优化。实际上，在Designing Partitions to Manage Subsets of Data中，AdventureWorks示例几乎与您的确切场景相匹配。

我会做一些研究，从这里开始，按照你的方式：Partitioned Tables and Indexes。

Answer 2

简单的解决方案：创建单独的表，取消规范化，其中包含所有字段。创建存储过程，它将根据您的计划更新此表。创建SQl代理作业以调用SP。

索引表格，你会看到它是如何被查询的。

如果您需要清除历史记录，请创建另一个表来保存它，并使用另一个表来填充它并清理主报表。

您可能会得到多个报告表 - 没关系 - 现在空间很便宜。