3

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

问题：我周一开会讨论这个项目，想知道是否有人可以提出一些有用的问题、理论、解决方案等。这不是我自己做不到，我只是认为另一种观点做不到伤害。另一个有趣的事实是，我可能获得也可能无法获得源代码，因为它可能是由承包商创建的，并且代码很久以前就丢失了。

旁注：是否可以访问自动存档旧记录？这意味着将它们转移到另一个名为 XXXArch 的数据库中。

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

编辑：

这是有关情况的更新。

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

4

3 回答 3

5

有几点需要考虑：

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

有人会建议在您的公司或此论坛中升级到像 SQL 服务器这样的“更大”数据库。除非您已经隔离了问题，或者除非您有性能以外的原因，否则不要这样做。这些问题很有可能是由糟糕的应用程序设计或数据库架构引起的。在不改变方法的情况下使用更强大的工具解决问题不太可能有帮助。

Access DB 将在数据最大化之前就最大化并发用户数。是否有很多用户（30 岁以上）刚开始使用该系统？这可能是问题的一部分。

存档旧记录：您将不得不建立一些东西来做到这一点。好消息是这并不难。

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

于 2010-10-15T13:46:19.780 回答
4

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

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

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

于 2010-10-15T14:11:15.093 回答
3

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

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

如果不是，则意味着该应用程序设计不佳，并且由于您缺少源代码，因此您无能为力。

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

最后，关于归档，我认为没有理由永远归档数据，除非你真的遇到了硬件/软件的硬性限制。在这种情况下，你甚至没有接近那个。

于 2010-10-16T16:39:16.473 回答