我正在编写一个存储过程来处理从csv文件填充数据库。大约有150个表，每个表将有1个CSV文件。
还有一些复杂的问题，即数据需要在导入时验证表进行验证。
我目前正在编写单个存储过程，它将csv文件名，表名和验证表名作为参数，然后处理从任何csv文件到任何表的导入。显然，这节省了150个存储过程，每个表一个。
但我的问题是，这是正确的方法吗？拥有这个通用的过程涉及使用相当多的动态SQL，并从我一直在阅读编写存储过程的地方，你不知道你将使用什么表，表格的模式等直到运行时，是一件坏事。它还需要使用全局临时表。但是，然后再写150个执行类似操作的存储过程也不是一个很好的解决方案，只有当他们必须知道要为哪个表调用哪个存储过程时才会混淆进行导入的人。
此导入将是一次性的事情，因此性能不是一个问题，并且运行它的唯一人员将拥有对数据库的完全权限，因此安全性不是问题。我想听听你对最佳方法的看法。
答案 0 :(得分：4)
在SQL Server中执行此操作的正确方法是SSIS包。它内置了各种各样的ETL工具。但由于这只是一次性的事情，我可能会以我知道的方式快速有效地编写它。我会写一点.NET。在你的情况下，它可能是一个sproc。
答案 1 :(得分：2)
“显然这可以节省150个存储过程，每个表一个”
我会质疑“拯救”。这里没有“拯救”。您已将150个简单的过程组合成一个复杂的过程。一个程序的复杂性超过了多个简单程序的任何“成本”。
“所以表现不是一个问题”
存储过程始终如此。他们很慢。做一些测量。您会发现Java或C＃将与存储过程一样快，并且通常比存储过程更快。
“但是，然后再写150个执行类似操作的存储过程也不是一个很好的解决方案，”
为什么？
您仍然拥有普通的软件设计 - 公共代码仍然可以分解为150个加载过程调用的过程或函数。每个表都不是一个不假思索的加载过程的复制和粘贴。您应该能够将每个存储过程减少到一些最小的唯一处理：验证和插入。
“此导入将是一次性的事情”
着名的遗言。那是不可能的。当您进行软件升级和数据库结构更改时，人们会建议他们将旧数据转储到csv中并使用这些存储过程（略微修改）来加载新数据库。你会经常使用这些。
没有什么是“一次性的事情”。
答案 2 :(得分：1)
如果您需要基于代码的解决方案，那么我将以您希望找到CSV文件的格式在SQL中设置表格。
然后我会编写代码来动态生成基于表结构的SQL，并逐行验证csv文件，以便在失败时提供一些明智的反馈。
易。然后你有一段代码使用它存储的数据库作为它的模式基础...一些驱动程序将csv文件名指向数据库中的表名。
保持150个存储过程听起来像一个总的球疼，这比它的价值更麻烦。重构应该让生活更愉快，而不是让人头疼。一切都很好，也可以扩展。
通常你不想生成sql，因为调试很困难，但是你可以逐个编写这个并使其高度可测试......因为你不接受不受信任的输入，可以减轻usul sql注入问题。
CSV导入程序总是尝试从简单开始，但实际上我发现需要5个步骤
你想用数据库驱动这个
然后，您可以处理将存储在类似位置的多个类似Feed，以及需要发送到多个类似位置的单个Feed。
答案 3 :(得分：0)
如果它们是直接映射，我倾向于使用bcp批量导入到表中。即使没有，我们经常使用批量导入到'原始'表中，然后运行一个过程来将导入的数据处理到主表中。
如果使用bcp传入数据不容易处理 - 尽管它可以处理CSV - 我的下一个选择是.NET SqlBulkCopy对象。
存储过程确实为您提供了安全边界 - 您可以对其设置权限，以便只有授权用户才能运行它 - 但如果它不经常运行，则不会带来巨大的性能优势。实际上，如果SQL Server以牺牲动态查询为代价来缓存查询计划，它可能会降低整体性能，并且内存足够紧，导致这些动态查询计划被丢弃。
答案 4 :(得分：0)
我认为可能 db存储过程对于一次性作业来说并不是最简单的解决方案。我的意思是阅读/解析CSV并将这些数据添加到表格中......这种事情在更高级别的语言中会更简单（ Java ， Python 等等。 ）。编写它并不是很复杂，更重要的是，维护它。当然，如果你的pl / sql（或任何等价物）很强大，那就选择一个复杂的。
我看不出有任何理由让150个不同的存储过程做大约。同一件事情。如果要添加20个表，会发生什么？ IT将成为存储过程的噩梦！