代码之家  ›  专栏  ›  技术社区  ›  Sam Cogan

通用存储过程

  •  1
  • Sam Cogan  · 技术社区  · 15 年前

    我正在编写一个存储过程来处理从csv文件填充数据库的操作。大约有150个表,每个表有一个CSV文件。

    我目前正在编写一个存储过程,它将以csv文件名、表名和验证表名作为参数,然后处理从任何csv文件到任何表的导入。显然这节省了150个存储过程,每个表一个。

    但我的问题是,这样做对吗?拥有这个通用过程需要使用相当多的动态SQL,而且从我读过的内容来看,在编写存储过程时,在运行之前,您不知道将要使用哪些表、表的模式等等,这是一件坏事。它还需要使用全局临时表。但是,再次指出,编写150个执行类似操作的存储过程也不是一个很好的解决方案,这只会让执行导入的人感到困惑,因为他们必须知道要为哪个表调用哪个存储过程。

    5 回复  |  直到 15 年前
        1
  •  4
  •   Chris Diver    15 年前

    在SQL Server中正确的方法是 SSIS 包裹。它内置了各种ETL工具。但由于这只是一次,我可能会做的方式,我知道我可以快速有效地编码它。我会写点.NET。对你来说,这可能是一场狂欢。

        2
  •  2
  •   S.Lott    15 年前

    显然,这节省了150个存储过程,每个表一个

    我会质疑“拯救”。这里没有“储蓄”。你已经把150个简单的程序变成了一个复杂的程序。一个过程的复杂性胜过多个简单过程的任何“成本”。

    “所以性能不是问题”

    存储过程总是这样。他们很慢。做些测量。您会发现Java或C将与存储过程一样快,而且通常比存储过程快。

    但是,再写150个执行类似操作的存储过程也不是一个很好的解决方案

    您仍然有普通的软件设计——公共代码仍然可以分解为150个加载过程调用的过程或函数。每个表都不是加载过程的不可想象的复制和粘贴。您应该能够将每个存储过程简化为一些最小的惟一处理:验证和插入。

    “此导入将是一次性的”

    没有什么是“一次性的事情”。

        3
  •  1
  •   John Nicholas    15 年前

    如果您想要一个基于代码的解决方案,那么我将以您希望找到CSV文件的格式用SQL设置表。

    然后我将编写代码来动态生成基于SQL的ont he表结构,并根据该结构逐行验证csv文件,以便在失败时给出一些合理的反馈。

    容易的。然后有一段代码使用它存储到的数据库作为模式基础。。。在数据库中将csv文件名指向表名的驱动程序。

    维护150个存储过程听起来像是一个总的麻烦,这比它的价值更大。重构应该让生活更愉快,而不是让维护变得头疼。

    通常你不想生成sql,因为调试是很困难的,但是你可以一个接一个地编写它,并使它具有很高的可测试性。。。由于您不接受不受信任的输入,因此可以减轻通常的sql注入问题。

    CSV导入程序总是试图开始简单,但实际上我发现需要5个步骤

    • 1) 您需要读取各种数据源类型
    • 3) 需要将这些逐行转换为一些内部表示并验证数据
    • 4) 需要将内部表示转换为其输出数据格式

    而这是由数据库驱动的

    然后,您可以处理将存储在相似位置的多个相似提要,以及需要发送到多个相似位置的单个提要。

        4
  •  0
  •   Mike Dimmick    15 年前

    bcp 如果是直接映射,则将导入批量到表中。即使不是,我们也经常使用大容量导入到“raw”表中,然后运行一个过程来处理导入到主表中的数据。

    如果传入的数据不容易处理 密件抄送 -尽管它可以很好地处理CSV-我的下一个选择是.NET SqlBulkCopy 反对。

    存储过程确实为您提供了一个安全边界—您可以对其设置权限,以便只有经过授权的用户才能运行它—但如果它不经常运行,则不会带来巨大的性能好处。事实上,如果SQL Server最终以动态查询为代价缓存查询计划,并且内存足够紧张,导致这些动态查询计划被丢弃,则总体性能可能会降低。

        5
  •  0
  •   Java Drinker    15 年前

    我想是的 也许 吧 数据库存储过程不是一次性作业的最简单解决方案。我的意思是读取/解析csv并将数据添加到表中。。用高级语言来说,这类事情会简单得多( 爪哇 蟒蛇

    推荐文章