我目前正在处理一个大型的项目来移动一个MS Access应用程序到SQL服务器。 我们的团队一直在讨论devise新数据库的一部分的最佳方法，所以我想我会提出反馈意见。
在当前的MS Accessdevise中，我们每天加载数据，然后在UI中进行处理。 由于我们仅限于Access的2GB大小，因此我们执行以下操作。
- 上午导入 – 首先删除前一天的数据，然后加载新数据
- 用户在白天处理数据
- 当天结束时，我们将数据库快照（基本上直接拷贝的Access数据库存储给用户，以便能够及时回溯研究）
在新版本中，插入到每个表格中的所有数据将具有分配给它的“业务date”，即它被添加到表格中的date。 然后在前端，用户界面将按date进行search以获取当天的logging。
现在我们正在考虑以下几点：
- 创build2个数据库 – 一个为当天，然后一个档案。 通常每天删除的数据将每天早上移到存档数据库。 对于前端，我们必须
UNION 2个数据库来获得最终的结果集
- 在同一个数据库中创build2个模式。 一个为当前和然后档案。 同样，我们将不得不
union数据，但它会在同一个数据库中
- 只是将数据留在当前的date表中，我们不需要UIsearch的数据。
让我补充一点，我们需要保存至less6年的数据加载到数据库，所以表格的大小将变得非常大。
我只是想弄清楚这种问题的最佳方法。 我相信我们不是唯一的这种情况。 我愿意提出任何build议，思考我们应该如何着手。
每个人都有可能的优点和缺点，可能有一个选项，你没有考虑。 这里有一些一般的意见，希望它有帮助。
- 创build2个数据库
- 维护变得稍微复杂一点，2个数据库保持同步，2个数据库pipe理备份，检查性能等。
- 前端访问变得稍微复杂一些，你需要联合数据。 我build议设置一个视图来处理这个问题，而不是把逻辑编码到你的前端。
- 维护操作更加灵活：备份，重build索引，表锁等都可以在两个数据库中独立进行，您可以将它们分离到不同的存储中以获得性能优势。
- 创build2个模式
- 我没有看到这种方法的其他两个选项中不存在的优点
- 对这种方法的一种认可是你使得访问更加复杂，但是你没有得到任何 （？）额外的维护或性能灵活性。
- 保持单一数据库，简单模式：
- 这具有简单的优点。 如果你不知道长期需要什么，如果你在SQL Server维护，devise等方面没有太多的经验，这可能是最好的方法。
- 主要的风险是你在一个地方得到了太多的数据，但是这可能会通过适当的索引来抵消 – 为了使数据库变得真正难以pipe理，你可能需要进入数百个演出
- 如果以后出于性能方面的原因需要进行分解，则可以随时实现选项1或选项4（甚至是2我猜） – 以便您可以“隐藏”实现来自前端的细节，甚至可能来自您的ETLstream程（尽pipe您可能不希望这样）
- 额外的选项分区与多个文件组
- 您可以将数据保存在一个数据库中，但可以将数据保存在不同文件中，可能位于不同的位置。
- 这可能是用大量数据处理“交换”和“交换”的最好方式（可能是将来的事情）
- 您仍然需要创build一个视图来合并基础数据
- 这仍然是相当复杂的，而不是你想要做的事 – 如果你发现你开始每天处理不合理的大量数据的话，你可能会考虑一下。
随机参考分区，看起来不错（对不起，没有做过彻底的search参考资料，并没有任何方便）： http : //www.sqlservercentral.com/articles/partition/64740/
您可以通过视图（date – math）将“当前”数据公开给用户。 单个数据库。