数据库压缩和归档 - MS Access 后端

Question

设想:有一个遗留程序（不确定是什么语言），我被要求“压缩并存档数据库中的表单”。当用户打开应用程序时，大约需要 2-5 分钟才能加载大约 27000 条记录！我的理论是它在启动时加载所有记录，但这可能不是唯一的原因。经过一番挖掘并找到看起来正确的访问后端后，我还在公司内 15 个以上的其他共享上发现了相同的访问文件。现在，这个应用程序是在 1997 年左右创建的，当时我猜测 Access 已成为常态，但他们真的会从 15 个以上的 Access 数据库中获取数据吗？加速该程序的标准似乎是将旧记录存档在另一个访问数据库中（这就是为什么我认为它在启动时加载所有内容。

问题:我周一开会讨论该计划，想知道是否有人可以提出一些有用的问题、理论、解决方案等。并不是说我自己不能做到这一点，我只是认为换个角度也没什么坏处。另一个有趣的事实是，我可能无法获得源代码，因为它可能是由承包商创建的，并且代码很久以前就丢失了。

边注:Access 可以自动存档旧记录吗？这意味着将它们转移到另一个名为 XXXArch 的数据库。

提前致谢。我会尽力回答您的任何问题。

编辑:

这是有关情况的最新情况。

看起来它只使用一个数据库作为主数据库，并使用一个数据库作为存档。我仍然没有自己的用户帐户来打开应用程序，但是在查看数据库时，有一个用户表，其中包含登录 ID 和相同的密码（密码），因此我尝试以这些用户之一的身份登录并简单地选择一些数据不修改任何内容。当选择时，我几乎能够立即获取数据，并且没有看到其他用户所遇到的任何放缓。我还没有看到源代码，但据我所知（获取 exe 并将其放入记事本中），它看起来像是用 VBA 编码的，并且可能是使用 MS Access 创建的。此外，应用程序似乎在数据文件夹中创建了 temp.mdb。目前它里面什么也没有。没有桌子，什么都没有。我假设/希望这是减慢用户速度的原因，可以将其删除以提高性能。一旦获得源代码并更好地了解是什么减慢了速度，我将发布另一个更新。

Answer 1

有几点需要考虑：

正如您在标题中指出的那样，如果经常使用 Access (MDB) 数据库，则往往需要定期压缩/修复。然而我很少发现它对性能的帮助超过最低限度。如果时间已经很长，文件可能会膨胀得很大，如果用户通过慢速网络连接访问它，这可能是问题的一部分。

有人会建议升级到“更大”的数据库，例如 SQL Server，无论是在您的公司还是在这个论坛中。在隔离问题之前或者除非有性能以外的原因之前，请勿这样做。这些问题很可能是由不良的应用程序设计或数据库架构引起的。在不改变方法的情况下使用更强大的工具来解决问题不太可能有帮助。

Access DB 早在数据达到极限之前就已经达到了并发用户数的极限。是否有很多用户（30+）刚刚开始使用该系统？这可能是问题的一部分。

归档旧记录：你必须构建一些东西才能做到这一点。好消息是这并不那么难。

访问 15 个以上数据库：您确定前端 GUI 不是用 Access 编写的吗？它是一种通用架构，可以将 MDB 前端加载到最终用户的计算机上（到处复制），连接到网络上的中央 MDB 数据文件。最好的判断方法是打开数据库，看看它们是否只包含表格，或者表格+表格/报告。

Answer 2

在我看来，您的首要任务应该是解决这个问题：

我可能无法获得源代码，因为它可能是由承包商创建的，并且代码很久以前就丢失了。

就目前情况而言，您要求我们推测缓慢的原因和补救措施......对实际发生的事情一无所知。

Answer 3

如果没有源代码，则无法将后端数据库更改为 SQL Server 或其他任何数据库。

但是，如果您确实有权访问数据文件并且能够编辑它们，为什么不检查索引呢？27K 记录对于任何数据库（包括 Access）来说都是微不足道的，而且加载数据的缓慢对我来说表明这些表根本没有正确索引。如果您检查表并发现明显字段上没有索引，则尝试添加它们并查看是否可以加快速度。

如果没有，则意味着该应用程序设计得很糟糕，并且由于您缺乏源代码，因此您对此无能为力。

当然，以上所有内容都假设网络环境适合 Access/Jet/ACE。也就是说，如果这些数据库文件是通过有线 LAN 以外的任何方式访问的，那么就无能为力（WAN 和 WiFi 完全不适合 Jet/ACE）。

最后，关于归档问题，我认为没有理由永远归档数据，除非您确实遇到了硬件/软件的硬限制。在这种情况下，你还差得远。