|
|
1
4
在SQL Server中正确的方法是 SSIS 包裹。它内置了各种ETL工具。但由于这只是一次,我可能会做的方式,我知道我可以快速有效地编码它。我会写点.NET。对你来说,这可能是一场狂欢。 |
|
|
2
2
我会质疑“拯救”。这里没有“储蓄”。你已经把150个简单的程序变成了一个复杂的程序。一个过程的复杂性胜过多个简单过程的任何“成本”。
存储过程总是这样。他们很慢。做些测量。您会发现Java或C将与存储过程一样快,而且通常比存储过程快。
您仍然有普通的软件设计——公共代码仍然可以分解为150个加载过程调用的过程或函数。每个表都不是加载过程的不可想象的复制和粘贴。您应该能够将每个存储过程简化为一些最小的惟一处理:验证和插入。
没有什么是“一次性的事情”。 |
|
|
3
1
如果您想要一个基于代码的解决方案,那么我将以您希望找到CSV文件的格式用SQL设置表。 然后我将编写代码来动态生成基于SQL的ont he表结构,并根据该结构逐行验证csv文件,以便在失败时给出一些合理的反馈。 容易的。然后有一段代码使用它存储到的数据库作为模式基础。。。在数据库中将csv文件名指向表名的驱动程序。 维护150个存储过程听起来像是一个总的麻烦,这比它的价值更大。重构应该让生活更愉快,而不是让维护变得头疼。
通常你不想生成sql,因为调试是很困难的,但是你可以一个接一个地编写它,并使它具有很高的可测试性。。。由于您不接受不受信任的输入,因此可以减轻通常的sql注入问题。 CSV导入程序总是试图开始简单,但实际上我发现需要5个步骤
而这是由数据库驱动的 然后,您可以处理将存储在相似位置的多个相似提要,以及需要发送到多个相似位置的单个提要。 |
|
|
4
0
如果传入的数据不容易处理
存储过程确实为您提供了一个安全边界—您可以对其设置权限,以便只有经过授权的用户才能运行它—但如果它不经常运行,则不会带来巨大的性能好处。事实上,如果SQL Server最终以动态查询为代价缓存查询计划,并且内存足够紧张,导致这些动态查询计划被丢弃,则总体性能可能会降低。 |
|
|
5
0
我想是的 也许 吧 数据库存储过程不是一次性作业的最简单解决方案。我的意思是读取/解析csv并将数据添加到表中。。用高级语言来说,这类事情会简单得多( 爪哇 蟒蛇
|