将基于 Access 的 VBA 工具迁移到独立的 .Net 应用程序会提高性能吗？

Posted 2023-05-07

【中文标题】将基于 Access 的 VBA 工具迁移到独立的 .Net 应用程序会提高性能吗？

【英文标题】：Will I see a performance improvement migrating an Access-based VBA tool to a standalone .Net application?

【发布时间】：2013-04-17 19:07:07

【问题描述】：

我了解这取决于应用程序。有问题的工具会遍历固定宽度的文本文件，并根据 Access 表中指定的一组验证规则进行检查。使用当前工具运行标准文件通过所有验证检查可能需要长达一个小时。

我可以将验证规则表迁移到 SQL Server 并将代码重构为独立的 VB.Net 应用程序。

我是否有理由期望看到性能改进？

【问题讨论】：

需要一个小时处理的文件有多大？有多少个验证规则？

在 Access 中花费了多少时间与处理文件花费了多少时间？验证规则有多大。为什么不将它们一次加载到 .NET 集合中。字典查找比 SQL 还要快。

文件有多大？规则是什么样的？具体是什么需要很长时间？不看代码就很难回答。

【参考方案1】：

这取决于很多事情，尤其是开发人员。我一直认为，技术差的优秀开发人员比技术先进的差开发人员可以生产出更好的产品。

在做出迁移决定时，有许多变量很重要。例如：

您当前的数据库是在服务器还是本地计算机上运行？我曾为那些拥有总是空间不足的服务器的大公司工作过。这确实会降低性能。使用大量内存在本地运行总是会更快。 当您运行这些规则时，这些表是在查询中使用还是在代码中使用？优化了吗？是否有许多级别的查询必须经过。尝试减少它们。 如果数据库中有大量 VBA，请尝试在代码中放入大量 debug.print，并在上面设置计时器，以便查看进程的哪些部分运行得快\慢。 是否有人在数据库运行时访问它？ 您需要索引表吗？有时索引过多会影响性能，尤其是在不需要时。 也许您可以尝试在导入文件时对其元素进行规范化，然后运行规则。 如果数据库当前未拆分为前端 - 后端，请尝试拆分它。也许它太大了（紧凑和维修）。

正如您在帖子中提到的那样，有很多变量处于危险之中，所以我不会急于迁移。相信我，我以前见过，如果不仔细分析您当前的情况，无法保证您会获得显着改善。

除了迁移之外，您还可以考虑的另一件事是自动化。我在一个 RAD 团队工作，该团队运行许多清晨流程。我们只是使用 Windows 计划任务在特定时间启动数据库、搜索和导入文件，然后处理它们。有些过程可能需要一个小时，但它们都在我们早上进入办公室之前就完成了，所以谁在乎它是否需要一个小时，只要它完成了。

【讨论】：

感谢您的建议。特别是使用 Windows 计划任务的想法。还有一个问题……在导入文件时规范化文件元素是什么意思？

您正在导入的文件的列中可能有很多重复。通过规范化表格，您可以消除表格中的冗余和重复，并使字段“原子”（单元格中只有一条数据）。其实还有很多，谢谢。例如。当您导入文件时，如果有任何列包含大量重复数据（例如用户名），您可以运行一些查询来提取值并将它们粘贴到带有 id 的连接中。然后将名称替换为该 ID。这是我知道的非常简短和简单的答案，但无论如何都值得一读以供将来参考。

【参考方案2】：

正如你所说，真正的答案是“这取决于......”但我敢猜测，根据你描述的处理类型，我不希望看到做在 Access VBA 中进行此类工作并在独立的 .NET 应用程序中进行相同类型的工作。

将后端数据库从 ACE/Jet 切换到 SQL Server可能会产生一些显着的性能优势，具体取决于所涉及的数据量以及某些验证是否可以从应用程序级别下推（VBA 或 .NET）到数据库级别（SQL Server）。但是，将后端迁移到 SQL Server 并不一定需要将应用程序代码从 VBA 完全移植到 .NET。根据您的具体要求，您可以拥有...

一个使用 ACE/Jet 作为后端的 Access VBA 项目， 一个使用 SQL Server 作为后端的 Access VBA 项目（链接表）， 使用 ACE/Jet 作为后端的 .NET 应用程序，或 一个使用 SQL Server 作为后端的 .NET 应用程序。

【参考方案3】：

使用 .NET 提高性能的最佳机会是将规则拉入内存（可能是规则对象的集合）并消除进程中的数据库瓶颈。

【参考方案4】：

如果您反复从 Access 表中提取规则，您可能会看到性能改进，但这很可能是您执行验证的方式导致了性能问题。一旦您将文本文件加载到内存中，.NET 将使您能够对文本文件执行并行操作，这可能会给您带来一些性能改进。但是，如果您的要求可以在所有行中实现，那么我认为您最大的改进可能是将文本文件中的数据提取到用 T-SQL 实现的 SQL Server 中，该 SQL Server 针对操作整组数据进行了优化，而不是逐行。或者从外部工具实现它们（.NET 会比 VBA 更快，是的）。

如果您不能/不想将文本文件拉入 SQL，请考虑在 .NET 中您可以将该文件拉入内存并使用多线程循环对其进行操作，根据您的规则进行测试。当然，有益的线程数是有限制的，但如果您有 4 个处理器，则最好使用它们。

【讨论】：

你认为他在 vb.net 中执行的验证可以在 TSQL 中执行吗？ TSQL 用于搜索不验证文本。与 .NET 相比，TSQL 字符串函数非常有限。

由于他没有指定 什么 他在 .NET 中进行验证，嗯，是的，我认为他可以在 T-SQL 中执行这些验证。至于与 .NET 相比，功能受到更多限制 - 我认为有很多事情可以在 SQL 中轻松完成（想想：搜索某些字符串并丢弃这些行），这正是数据库引擎的构建去做。此外，如果数据是固定宽度的，它很可能很适合表格结构，这意味着在批量加载表格时可以丢弃相当多的有问题的记录。

真的，他正在对 VB 中的文本执行验证，您的答案是在 SQL 中加载该文本并使用 TSQL。您可以将一行加载到 SQL 中以搜索它们以丢弃行，而不是在 VB 中一次验证一个文件。如何删除行验证？无需将此文件数据加载到数据库中。

我认为你已经被这一点分心了，真的。感谢您的-1。您是否阅读我的其余建议，或者您只是对使用数据库有偏见？ OP 中没有说明什么类型的验证，也没有说明进一步的要求是什么，所以我提出了一个建议。现在我们在 cmets 中讨论一些可能对 OP 的要求没有任何意义的东西，因为没有详细说明它们。活下去，也许吧？

如果我在文件 VB 中有文本，我会产生偏见，为什么要将文件加载到 SQL 中以在 SQL 中验证它。将文件加载到 SQL 中需要时间。没有验证我可以在 .NET 中更快地完成的 TSQL。不需要将文件加载到 SQL 中。我喜欢数据库——当我需要数据库时。