4

我们使用 Access 数据库作为我们软件产品的后端。该程序已经在一家公司进行了大约 2 年的 alpha/beta 测试，我们注意到我们的一张表在此期间已经填充了超过十万条记录。这可能不是我们产品将承受的最大使用量的例子，我们担心未来 5 到 10 年的性能。

我们有一种合乎逻辑的方法可以将这个巨大的表分解为包含几百条记录的几千个表，但我认为这个解决方案不会有助于任何可能的减速，因为数据库将变得臃肿，而不是数据（虽然我没有接受过数据库方面的正式培训，但我知道什么）。

我希望比我更了解情况的人可以提供一些见解，了解我们是否可能会看到显着放缓，如果是这样，哪种解决方案可能会长期保持更好的性能？

4

5 回答 5

2

数据库通常经过优化以处理大量行；问题是，您能否维护数千个几乎相同的表？（很少可以，编码很复杂）

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

如果发现您的表大小有问题，并且您的数据集可以分为较少使用（较旧？）和最近的数据，我建议将表一分为二：table 和 table_archived（包含较少使用/较旧的记录） . 这可能是表大小和可管理性之间的合理折衷。

于 2010-07-20T20:42:02.293 回答
1

这么多地分解表听起来有点矫枉过正，但水平分区是一种非常合理的性能优化策略，在许多数据库平台中都使用。

使用 MS Access，您不会在设计良好的读取数据库上看到性能下降太多，即使有数百万行也是如此。此外，如果您经常压缩和修复它，拥有大量表不会导致性能问题，但更大的问题是维护的复杂性。我会说不要拆分表，直到它至少有一百万行和/或显示该表上的查询存在性能问题。

这就是问题所在：如果用户不断地查询一个分区中的多个表，而您需要将这些表重新组合在一起，这种类型的分区会严重影响性能。在分区包含不经常搜索的档案记录的情况下，它的效果要好得多。如果您认为您需要经常跨表查询，请不要去那里。

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

于 2010-07-20T20:40:31.827 回答
1

这个问题是一个模式问题，如果您正在考虑的表分区不适合实际数据，它将加剧性能问题，而不是改善它们。关于 2GB 文件大小限制，您如何对数据进行切片和切块可能并不重要——如果您接近该限制（我会说在 50% 以内），您真的需要一个升迁路径。

关于 Jet/ACE 数据存储的问题，我会说任何拥有包含数千条记录的表的应用程序都应该被评估为升迁。如果有可能/可能拥有数百万条记录，我会说这是不费吹灰之力 - 升级。

这并不是因为 Jet/ACE 有任何不足，只是因为随着需求的变化，相应的技术也会发生变化。一对已婚夫妇在结婚时可能会发现 Mini Cooper 很好，它可能适合他们的第一个孩子，但如果他们正在考虑再生几个孩子，他们真的应该认真考虑买一辆更大的车——不是因为有什么问题使用 Mini Cooper，但因为它们已经超出了它最适合的范围。

于 2010-07-21T18:20:16.187 回答
0

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

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

我们担心未来 5-10 年的表现

鉴于 lat - hm - 10 年的发展，我不会。我会非常担心 Access 在 10 年后是否真的仍然能够存储数据，或者调用是否在两者之间的某个时间点是“sql server 程序”。

我们有一种合乎逻辑的方法可以将这个巨大的表分解为包含数百条记录的数千个表，但我认为这个解决方案可能不会帮助解决任何可能的减速问题，因为数据库将变得臃肿而充满表而不是数据

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

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

您更有可能死于访问 - 访问根本不是数据库服务器。回到绘图板。

也就是说，大约 18 年前，Access 添加了一些从 FoxPro 获得的技术，使其能够轻松处理具有数百万条记录（不是数千万而是数亿条记录）的表，因此您此时非常安全（除了尝试对类似的东西进行数据库修复、备份等，甚至是通过网络共享运行多用户应用程序的噩梦。

SQL Server，otoh，我有一张表，目前约有 6.5 亿条记录，在数据加载开始后的未来 6 个月内增长到约 10 或 200 亿条，到目前为止没有任何问题。

于 2010-07-20T20:41:45.883 回答
0

我将避免在此线程中进入 access –v- SQL server 辩论，而只是回答 OP 的问题。

如果可以拆分数据并且人们不会在这些拆分中进行查询，那么它可能是一个值得测试的选项，但是有 2048 个开放表的访问限制，因此您可能需要注意这一点。

然而，之前有人说过，如果你不得不问某事的最大数量是多少，那么你很可能做错了，我认为这就是一个例子。如果将其拆分为 10 张桌子，但可能是数千张？我会传递那个

于 2010-07-21T07:16:40.650 回答