我正在寻找允许我们的用户上传 XLS 电子表格的最佳解决方案，以便它们可用于填充我们的数据仓库 (DW) 中的表。
我们的用户是重度业务对象 (BO) 用户，BO 允许您导出到 XLS。当他们在电子表格中有数据需要加载到 DW 时，他们需要一个过程将 XLS 中的数据上传到 DW 的数据库中。结果，当我认为我们真正需要的是程序化自动提要时，我们最终得到了许多这样的“接口”。在我的直觉中，使用 Excel 作为系统间馈送的数据源对我来说似乎是个坏主意。
问题#1：我想看看你是否同意以及为什么或为什么不同意。
好的，没有逆流而上，所以我现在认为 XLS 上传会为我们保留。现在我需要找到最好的解决方案。首先，我将解释我们现在做什么，然后解释我不喜欢它的地方：
通过网页，我们提供带有一组已定义列的空 XLS 文件（无行）。每个文件旨在用于更新不同的目标目标表。在每个电子表格中都有一个“上传”按钮。按下上传按钮会导致电子表格中的宏将文件的内容序列化为 CSV 并将数据通过 FTP 传输到服务器文件夹。调度程序会定期触发 Informatica ETL 作业，该作业使用 CSV 文件作为输入并将数据加载到自定义 XLS 特定临时表中，然后，如果记录通过编辑，则加载到相应的目标表中。遇到的任何错误都会记录到错误表中。对于上传的每个 XLS 文件，数据最终会出现在文件特定的单独暂存和错误表中。
关于我们的流程，我不喜欢的一些事情是：
1) XLS 中的宏代码过于暴露，例如包含密码，可以被篡改，并且存在确保用户使用最新的 XLS 模板的问题。2）业务规则编辑被放置在ETL程序中，它们可能应该在哪里，但是因为我们想尽快捕获错误，即在电子表格中，编辑也被添加到宏代码中。这会导致业务编辑重复。我希望将这些规则集中在一个地方并集中控制。恕我直言，我认为在 XLS 中放置任何宏代码都会引入维护问题，甚至调用存储过程（其中一些我们有）或调用 Web 服务（我们还没有尝试从 XLS 宏调用 .NET Web 服务。) 3) 每个 XLS 文件上传模板都有自己的流程，其中包含一组不同的暂存和错误表，以及用于报告遇到的错误的自定义屏幕。似乎我们需要一个更通用的可重用解决方案。
除了经常将数据从 BO 导出到 XLS 之外，用户还喜欢 Excel，因为它比通过 Web 界面编辑单个记录更容易编辑大量记录并且不那么笨重。
这是我想的大方向：
首先，我希望用户能够通过编辑轻松编辑 Excel，但无需在电子表格中包含嵌入的宏。我尝试了与 Excel 兼容的 Farpoint 网格...
http://www.fpoint.com/netproducts/spreadweb/tour/excel.aspx
...而且我发现让用户能够打开驻留在其 PC 上的 XLS 文件并让它在浏览器中打开并能够轻松访问从服务器端读取的数据非常容易。 NET 网络代码。Excel 没有在他们的浏览器中本地运行，但 Excel 的功能被复制了，大概是通过大量客户端脚本，我希望复制自己会很痛苦。您甚至可以从本地电子表格剪切并粘贴到网络电子表格中。这听起来不错，最大的问题是成本。我们公司濒临死亡，不允许我们购买任何新软件。
接下来，我想确定所有电子表格上传处理中的通用组件，并提出通用处理代码。例如，我想象一个表格，它定义了我们的每个电子表格以及每个表格的格式，包括列名和数据类型定义，可能是根据它们的目标列而不是硬编码。基于这个表模板定义，我可以从这个表定义中生成 XLS 模板供下载。我还可以执行简单的通用编辑以确保输入的数据与表定义匹配。并且可以使用一个通用网页来呈现数据并允许报告数据类型不匹配错误并允许用户更正它们。我还将定义一个通用表，用于将数据存储在“暂存”表中，使用具有两列的表，提交编号、行数、名称和值，也许。目标不再是“定制一切”。
接下来我需要决定把业务规则放在哪里。我部门的管理人员坚信所有数据加载都应由 Informatica ETL 批处理完成，因此规则/编辑属于“Informatica 中”。我对 Informatica 工具的经验为零，我更像是一个 .NET 人。因此，我不确定这些规则是如何实现的，但我怀疑它们是不可重用的，因为它们可以被 .NET 网页用来验证特定记录。您会看到，在某些情况下，当用户不执行批量上传时，他们确实能够编辑特定记录，我希望将 ETL 批量插入过程应用的相同编辑应用于单个更新尝试通过网页记录单个记录。如果解决方案可以编写单个 Web 服务或存储过程，可以从网页调用来更新单个记录，或者在批量上传中为每条记录调用数千次？后者听起来效率低下。
您对以上任何内容的想法将非常受欢迎。