3

我有一个从 MS Access 数据库中提取信息的 VB.NET Windows 应用程序。该应用程序的主要作用是从各种格式的 Excel 文件中提取信息,标准化文件布局并将其写入 csv 文件。该应用程序使用 MS Access 作为密钥和交叉引用文件的来源。

Windows 应用程序使用类型化的数据集进行数据库之间的大部分用户交互。标准化是在每台客户端机器上完成的。该应用程序不是...我怎么能这么说...FAST :-)。

问题:将数据库和应用程序迁移到 SQL Server 2005 的最佳方法是什么。我认为在 SSIS 包中编写用于标准化的代码可能是个好主意。

进行此迁移的适当方法是什么?


该应用程序每周从 250 个 excel 文件和每月大约 800 个文件中提取数据,每个文件平均大约 5000 行。有 13 种不同的文件格式被标准化并输出为 3 种不同的标准格式。该应用程序需要 25 分钟。并且运行 40 分钟,具体取决于我们要运行的数据。95%的申请是标准化过程。用户所做的只是选择一些参数然后开始运行。

4

5 回答 5

2

Microsoft 提供了一个免费工具来将 Access 数据库迁移到 SQL Server。升级后,您应该能够将连接字符串更改为指向 SQL Server。

于 2008-11-01T01:26:50.830 回答
1

您可能希望通过分析器运行您的应用程序,以确保 Access DB 确实是降低您的应用程序速度的原因,而不是其他原因。完成所有工作以将其转换为 SQL Server 并且没有什么可展示的,这将是一种耻辱。

于 2008-11-01T01:28:04.713 回答
1

Access 升迁向导可用作起点。

您可以在不更改前端的情况下将后端更改为带有 Access 中链接表的 SQL Server。然后,您可以随意修改前端直接进入SQL Server。

除非您对 Access 的打击很大,否则我怀疑这是您的瓶颈。

就读取 Excel 文件而言,SSIS 可以做到,但它可能不如您现在在 VB.NET 中使用的机制可靠,如果您的 VB.NET 代码有很多智能逻辑来处理学位输入文件的变化

就将数据写入 CSV 而言,SSIS 很好,而且我发现 SSIS 的表现非常好。

如果您可以提供有关工作流程以及用户与数据库交互的程度以及程序拉取配置的更多详细信息,则可能更容易帮助您的体系结构。

SSIS 非常易于动态配置(程序包在运行时对其自身进行了一些配置),并且在许多情况下,它可以被编程为读取各种 Excel 文件并将它们转换为 CSV,但它不像手动配置那样动态配置编码系统。也可以使用 SSIS 对象模型以编程方式生成包然后执行它们 - 这没有包配置自身的一些限制,但对象模型非常复杂。

于 2008-11-01T01:32:05.030 回答
0

确保范围明确:

  1. 使用 .NET 程序
  2. 驱动 Access 数据库前端,使您能够
  3. 从多个 Excel 电子表格中提取数据,
  4. 适当地按摩数据,以及
  5. 将结果保存在 CSV 文件中。

我们在谈论什么类型的卷?有多少个客户,每个客户有多少个电子表格,每个电子表格有多少行(我认为单个电子表格最多 32767,对吧?我们在谈论多少时间?

似乎有很多活动部件。Access 通常是一个非常好的工具(使用 VBA)可以自行完成这类事情。

对于设计良好的 Access 数据库前端 Excel 使用 VBA 完成整个过程,它似乎没有足够的容量来提供主要的时间接收器。如果您的替代方案涉及在每个客户端上安装和操作 SQL Server(代替 Access),那么如果管理和操作开销没有增加,我会感到惊讶。

于 2008-11-01T01:40:03.173 回答
0

因此,每周,每个客户:25 分钟 250 个文件 = 10 个文件/分钟或每个文件 6 秒。

每月,每个客户:40 分钟 800 个文件 = 20 个文件/分钟或每个文件 3 秒。

我的期望会小于 1 秒。每个文件(5000 行)往返包括
:将 xls 导入或附加到 mdb,
b。通过 Access SQL 转换
c. 导出为 csv

想到的唯一解释是,.NET 应用程序可能一次读取、转换和保存一行。有可能是这样吗?

如果您转换为 SSIS,那么这可能会使 .NET 应用程序过时,因为 SSIS 将希望自己处理 ETL(并保存)。所以你基本上会重写软件。但是您可能拥有比 Access 更好的 SSIS 资源。但在我看来,这有点矫枉过正。但是,.NET 而不是 VBA 也可能是矫枉过正;并且用 VBA 重写也是可行的。我认为最少的努力是看看你是否可以使用 Access SQL 来完成整个 ETL(并保存),并且只使用 VBA 来编写脚本,遍历目录中的输入文件等。

我认为您至少可以对基本用例进行原型设计,并找出您是否可以很快找出现在花费的时间(如先前的回复所建议的那样。)但是在提交针对问题的错误部分。如果您可以在这些领域进行一些扩展,我可能会进一步指导您。但是 Access 非常适合这种事情,在(恕我直言)比 SQL Server + SSIS + .NET 更低的 TCO。

更不用说如果 csv 文件是真正的终点,我会感到惊讶,这可能会在决定中发挥作用。Excel 数据真的不会走得更远吗?

最后,一个 25 到 40 分钟的过程可能是无人看管的,可以在午休时间运行,并且可能基本上可以正常工作,这有多令人反感?


笔记:

每个星期    

Excel 文件 250
分钟 25
分钟/文件 0.1
秒/文件 6


每月   

Excel 文件 800
分钟 40
分钟/文件 0.05
秒/文件 3
于 2008-11-01T03:37:37.087 回答