问对Access数据库性能影响更大的是数千个表还是数百万条记录？

EN

该程序已经在一家公司进行了大约两年的alpha/beta测试

在过去的大约10年里，微软一直建议人们不要使用Access作为数据库，而是使用SQL Server的各种版本。

，我们关心的是未来5-10年的性能

考虑到最近10年的发展，我不会这样做。我会认真地关注Access在未来10年里是否仍然能够存储数据，或者在这两者之间的某一时刻调用的是否是“sql server的程序”。

我们有一种合理的方法将这个巨大的表分解为包含几百条记录的几千个表，但我认为这种解决方案不太可能有助于任何可能的减速，因为数据库将变得臃肿，其中包含的是表而不是数据

Access能够很好地处理一百万或五百万条记录。SQL Server可以很好地处理数十亿条记录。当你遇到Access的问题时，基本上，你得到的任何问题都是基于-我真的找不到更好的说法-甚至尝试使用access来处理严肃的数据库的巨大无知，正如我已经说过的那样，微软在过去10年里一直不鼓励这样做。

从一个表中拆分数千个表是不明智的；SQL数据库不是为此而设计的。即使在SQL Server Enterprise中使用聚集表(这样做)也不能真正针对拥有数万个分区的用户。

你更有可能死于access -- access根本不是一个数据库服务器。回到绘图板。

也就是说，大约18年前，Access添加了一些从FoxPro获得的技术，允许它轻松地处理包含数百万条记录(不是数千万条，而是数亿条)的表，所以此时您是非常安全的(除了尝试对这样的东西进行数据库修复、备份等的噩梦，甚至是通过网络共享运行多用户应用程序的噩梦)。

SQL Server，otoh，我有一个表，目前大约有6.5亿条记录，当数据加载开始时，在接下来的6个月里会增长到大约100亿或200亿条记录，到目前为止没有任何问题。

数据库通常经过优化，可以处理大量的行；问题是，您是否能够维护数千个几乎相同的表？(很少有人能做到，用它编写代码很复杂)

首先，测试可能的场景。我不熟悉你的数据，所以我不能告诉你数百万行对于数据库来说是不是太多了(毕竟，这是MS Access，不是真正的数据库)。

如果发现表大小有问题，并且您的数据集可以划分为较少使用的数据集(较旧的？)对于最近的数据，我建议将表拆分为两部分: table和table_archived (包含较少使用/较旧的记录)。这可能是表大小和可管理性之间的合理折衷。

将表分解那么多听起来有点过分，但horizontal partitioning是一种非常可靠的性能优化策略，在许多数据库平台中使用。

使用MS Access，即使有数百万行的数据，在设计良好的数据库上也不会有太大的性能下降。此外，如果您经常压缩和修复表，那么拥有许多表也不会造成太多的性能问题，但更大的问题是维护的复杂性。我建议不要拆分表，除非表中至少有一百万行和/或该表上的查询显示出性能问题。

这就是问题所在:如果用户经常跨分区中的多个表进行查询，而您需要将这些表重新组合在一起，那么这种类型的分区可能会大大降低性能。在分区包含不经常搜索的归档记录的情况下，它的效果要好得多。如果您认为需要频繁地跨表查询，请不要这样做。

您最大的可伸缩性障碍将与用户数量相关。如果您预计有100个用户，则需要非常仔细地计划，或者可能考虑客户端-服务器数据库后端。