目前，我正坐在一个用Access编写的丑陋的业务应用程序中，该应用程序每天都会使用电子表格并将其导入MDB。我目前正在将包含此项目的主要项目转换为SQL Server和.net，特别是在c＃。
中为了容纳这些信息，有两个表（别名在这里），我将调用Master_Prod和Master_Sheet连接到Master_Prod表ProdID的父标识密钥。还有两个表来存储历史记录，History_Prod和History_Sheet。有更多的表格延伸到Master_Prod之外，但为了便于说明，将其限制在两个表格中。
由于这是在Access中编写的，因此处理此文件的子例程中充斥着手动编码的触发器来处理历史记录，这些历史记录一直是并且一直很难跟上，这就是为什么我很高兴这会转向数据库服务器而不是RAD工具。我正在编写触发器来处理历史记录。
我的计划是创建一个对电子表格建模的对象，将数据解析到它中并使用LINQ在将数据发送到服务器之前对客户端进行一些检查...基本上我需要比较表格中的数据到匹配的记录（除非不存在，然后是新的）。如果任何字段已被更改，我想发送更新。
最初我希望把这个程序放到某种接受IEnumerable列表的CLR程序集中，因为我已经有了这种形式的电子表格，但我最近才知道这将与一个相当重要的数据库配对服务器，我非常担心陷入困境。
这值得将CLR存储过程用于吗？还有其他入口点，数据进入，如果我可以构建一个过程来处理它们给定传入的对象，那么我可以从应用程序中采取大量业务规则，但代价是潜在的数据库性能。
基本上我想从客户端进行更新检查并将其放在数据库中，以便数据系统管理是否应该更新表，以便历史触发器可以启动。
关于更好地实现这一目标的思考？
答案 0 :(得分：3)
使用SSIS。使用Excel Source阅读电子表格，可能使用Lookup Transformation检测新项目，最后使用SQL Server Destination将缺失项目流插入SQL。
SSIS 方式更适合这些从头开始写作的工作，无论linq有多么有趣。 SSIS包比一些忘记源的dll更容易调试，维护和重构。此外，您将无法匹配SSIS在管理高吞吐量Data Flows的缓冲区时的优化。
答案 1 :(得分：2)
本来我原本希望这个 程序进入某种CLR 接受IEnumerable的程序集 列表，因为我将有电子表格 以这种形式，但我最近 得知这将是配对的 有一个相当重要的数据库 我非常关心的服务器 陷入困境。
不起作用。对C＃编写的CLR过程STILL的任何输入都必须遵循正常的SQL语义。所有可以改变的是内部设置。与客户端的任何通信都必须在SQL中完成。这意味着执行/方法调用。无法直接传入可枚举的对象。
答案 2 :(得分：1)
我的计划是创建一个对象 对电子表格进行建模，解析 数据进入它并使用LINQ做一些 在发送之前检查客户端 数据到服务器...基本上我需要 将表格中的数据与a进行比较 匹配记录（除非不存在， 然后它的新）。如果有任何字段 已被改变我想发送 更新
您可能需要为您的方法选择“中心” - 即以数据为中心或以对象为中心。
我可能会先适当地建模数据。这是因为关系数据库（甚至关系数据库中表示的非规范化模型）通常比客户端工具/库应用程序更长。我可能会开始尝试以正常形式进行建模，并考虑在此期间提及的维持审计/历史的触发器。
我通常会想到进来的数据（实际上不是对象模型或实体）。那么我就专注于输入的格式和语义，看看我的数据模型中是否存在错配 - 也许我的数据模型中存在不正确的假设。是的，我不打算制作一个验证电子表格的对象模型，即使电子表格是众所周知的变幻无常的输入源。和Remus一样，我只是简单地使用SSIS将其引入 - 可能是一个临时表，然后在将它应用到带有一些T-SQL的生产表之前再进行一些验证。
然后我会考虑一个客户端工具，它具有基于我的良好实体数据模型的对象模型。
或者，对象方法意味着对电子表格进行建模，但也需要将对象模型保存到数据库中 - 也许您现在有两个对象模型（电子表格和完整的业务域）和数据库模型（存储持久性） ，如果电子表格对象模型不如系统的业务领域对象模型那么完整。
我可以想到一个例子，我有一个像这样的一次性外部对象模型。它读取“主文件”，它是描述输入文件的布局文件。该对象模型允许程序构建SSIS包（以及BCP和SQL脚本）以导入/导出/对这些文件执行其他操作。实际上它是一个一次性对象模型 - 它不是用作行中数据的实际模型或父行和子行之间的任何类型的导航等，而只是用于内部目的的内部表示 - 它不一定对应于“域”实体。