【讨论】关于数据层用不用存储过程封装的问题？

yulihua49

newkid 发表于 2012-7-23 03:09
几年过去了你还在搞这个批量插入做例子，有点新意行不行啊？
我的答复还像几年前一样：用外部表，可以IN ...

这是个新项目，用的老方法。
这些方法的可重用性非常好，一次构建代码，到处用。

没有新意，这些方法可以一直用下去，不过是告诉后来者，世界上还有一种方法。。。。。。。。
因为老问题在不停的被新提出来。
这个活很典型，存储过程不灵。
所以你的意见要加一个“一般说”。

你的老办法永远没我快。

从网上传来1千万的数据怎么往存储过程提交（一个一个记录的？），当然是在本地SQL批量插入最快。

还要插临时表，还要merge，没那闲功夫。

扣题：
用不用存储过程不能一概而论，要看实际情况。

newkid

yulihua49 发表于 2012-7-24 12:27
这是个新项目，用的老方法。
这些方法的可重用性非常好，一次构建代码，到处用。

我说的不是临时表，是“外部表”，就是把文件当作表来访问。这要求把文件上传到服务器。
数据如果还在客户端，当然要从客户端来插入，用批量绑定；
到了数据库之后，那就是SQL 和 PL/SQL 大显身手的时候，没你什么事。

yulihua49

newkid 发表于 2012-7-24 23:35
我说的不是临时表，是“外部表”，就是把文件当作表来访问。这要求把文件上传到服务器。
数据如果还在客 ...

这个单位的老前辈，他们水平也不差，就是用你这个办法，不灵。所以才请我来，用我的办法，解决了。
五月间还在用csv映像做最后的努力。说实在的，人们还真是支持你的多，压倒多数的多，他们也是想用存储过程解决问题。
问题到了这个节骨眼，实在不行了，才不得不用我的办法。
原来11小时的计算量我用半小时解决了。说明一点，原来也不是存储过程，是STL，是基于关系数据库的STL（C++标准模板库）（虽然表被调入内存，但依然没脱离关系模式）。如果用存储过程，10个11小时也弄不完。现在（经过长时间反复的算法分析）弄成层次型数据库，仅仅用关系数据库做持久化。用层次型数据库才最终提高了性能。脱离了关系模式，存储过程根本使不上劲。我的办法（虽然这里只是个特例）实现了用最快的速度在关系数据库和层次数据库间来回调动数据。可以这么说，我的方法高效的实现了关系数据库对外部更广阔的世界的数据纽带。而存储过程把世界禁锢在关系模型中。

回到主题，不是什么事情都要用存储过程（我承认存储过程能做很多事情，也做得很好，但不是所有）。要看实际情况。
我不反对使用存储过程，我反对的是：“一切皆存储过程，一切皆SQL，一切皆关系”。

newkid

我还曾经把运行27小时的存储过程调成半小时的呢！SQL, PLSQL的写法也大有讲究，并不是说用了“我的方法”就如何如何。
你别整那些虚的，就简单说说这个任务做什么，数据从哪里来到哪里去，11个小时花在入库还是计算，举个简化的最能说明问题的例子讲讲这个“层次模型”是如何化腐朽为神奇的。

dingjun123

还在讨论啊

lastwinner

熟悉什么就用什么
存储过程不是什么都能做的，同样，java/c等也不是什么都能做的，这时候适合用什么就用什么

gszoracle

熟悉什么就用什么，只要机器扛得住就行。当然有规范的要遵从。

yulihua49

lastwinner 发表于 2012-7-29 00:16
熟悉什么就用什么
存储过程不是什么都能做的，同样，java/c等也不是什么都能做的，这时候适合用什么就用什 ...

我就是这个意思，任何一种工具都有自己的优势和局限性。

yulihua49

newkid 发表于 2012-7-28 23:40
我还曾经把运行27小时的存储过程调成半小时的呢！SQL, PLSQL的写法也大有讲究，并不是说用了“我的方法”就 ...

北京地铁清分系统。
根据UD（User Data)就是交易记录，得知进站(O)、进站时间、出站(D)、出站时间。
基础数据：车站线路表、路由表（每个OD有N个有效路径，及使用概率）、运行图（时刻表）
各换乘站换乘走行时间表，每个站在平日工作日、休息日、节假日、高峰期和平期的平均走行时间是不同的，要根据具体时刻选择。
各换乘站留乘次数概率表，也是与日期时段相关的。
计算：这个UD经过了哪条路径，哪个线路的里程（米），按照里程比例为每条线路清分票款，并计算各站各线各时段客流(这个不归我)。
这个UD具体走哪条线路，在某个站可能不是它遇见的第一班车，而是等了几班（留乘）。UD可能参数不全（前边的4个条件，但O、D至少要有一个）
日期可能跨日（头天出站没划上卡，后来补划，不一定什么时候，在哪站补），卡有很多种清法不一样。
每天现在500万，将来1100万UD，2小时算完。数据在传输、处理过程中要求不重不漏。

每个UD要计算出所有可能的方案，在其中评估出一种。

原计算11小时完全是计算时间，数据库时间忽略不计。主要时间花在检索数据，主要是检索运行图。
检索是在内存，几个个多线程共享的vector,multimap,hashmap...........主要结构仍然是关系。
算法不是我做的，我不知道。我只管解决检索瓶颈。就是说，这是一个数据－程序分离的系统，跟存储过程根本不是一个路子。

说的我都累了，也跑题了，还说吗？项目的用户需求好几百页。。。。。。。
这又是一个特例，不具普遍性。我只想说，存储过程不能包打天下。
关系也不能包打天下，至少有时性能不行。
几乎所有的基础数据都改了层次模型。以时刻表为例：
查询需求：
一个UD在某时刻到达某站，他可能搭乘这个时刻之后某班列车，或来自这个时刻之前的某班列车。
找到这个列车的车次，方向（上下行）等等，得到这个车次的全部经由站，并选择其中的上车站和下车站（可能其中缺一，发生换乘）。
得到其间的运行时间和下一段的乘车时刻。
关系模型：
线号、车次、方向、停靠站、进站时刻、出站时刻。。。。。。。每个站一条记录，每天100000记录。
发生两次检索，第一次根据车站、方向、时间找到一个记录（小于指定时间最晚的或大于指定时间最早的）。
根据这个记录的线号、车次、方向找到这个车次的全部停靠站。
用SQL,这个过程至少300微秒，STL也需要20微秒。
层次模型：
由 线号、车次、方向、停靠站数 组成第一层，车站、进站时刻、停站时间、、、、组成第二层
第一层有指针指向第二层数组的首记录，每个第二层记录有指针指向它的父节点。
检索发生在第二层，由KEY：车站代码、方向号、时刻；检索方法：>,>=,<,<=之一。
找到第二层的一个记录，它的父指针指出了这个车次的所有停靠站，检索只发生一次，3微秒。

原来的关系存储，每次更新运行图的记录太多，调入速度太慢。
改成：线号、车次、方向、停靠站数、停靠站列表（车站,时刻,时间,车站,时刻,时间,,,,,)，每个车次一个记录，每天4000－5000个记录，调入速度提高了一个数量级。但是这个结构在SQL中是无法检索的。

最后，计算是多服务器多线程并行的，每1000个UD一组，全部计算完毕一次批量插入数据库。
另外，这个UD有146个字段，我只处理其中十几个字段。其它从我手中过，不能丢。这就用到我以前说的柔性处理，在我的程序里操作SQL时，不写列名，让模板系统去处理。既减少了维护量又增加了可读性。提交给他们计算的UD结构，他们也只使用其中很少的列，其它列名都枚举出来也是没有意义的。这在大型数据处理系统很常见，一个工序只处理一部分列。一个工序改变了自己的列对别的工序应该影响尽可能小。
那个插入语句在这里，自动生成的，其中绝大多数列我自己都不知道是啥，要是手写。。。。。。。：
http://www.itpub.net/forum.php?mod=viewthread&tid=1636899&page=3#pid19864500

架构：一个管理器，接收前方发来的UD，分成1000个一组。以负载均衡的方式发送给后方的多个计算服务器。每个计算服务器有多个线程，共享一组基础数据。你的存储过程就算是猛虎，也想与群狼匹敌？

这个题目，什么方法都可以实现，只是性能不同。

duucoo

等待高手解答