re: 关于数据库存储过程的一些讨论

yulihua49

newkid 发表于 2014-6-5 10:39
你的“很多时候”，很多时候就是数据加载卸载，并不是我们讨论的业务逻辑这个领域；数据加载现在有外部表 ...

广义来说，交易，就是数据加载卸载。
从客户端拿到数据，处理（可能与数据库内的数据有关），然后进入数据库。
或
前端请求一个数据，从数据库提取，加工一下，发到客户端。

就是这样一个流程，有时（不是全部），比存储过程快。

所以，我不反对你的观点，但它不是全部。我的也不是全部，我们加起来大概差不多了。

yulihua49

newkid 发表于 2011-2-12 10:48
异步操作的代价是复杂化，往往伴随着分布式事务。还要牺牲用户体验，因为虽然响应时间快了，但是得不到一 ...

响应时间基本没变，只不过你在等待期间，线程给其他人服务去了。良好的异步系统可以显著提高响应能力和吞吐量。
但是的确设计复杂，容易出错。我做了若干交易系统，成功而且收到成效的异步系统只有一个。不过这个与讨论的题目也没什么关系，异步系统也可以使用存储过程，不过异步化是中间件干的事。
自己从0开始写异步处理逻辑，几乎是件不靠谱的事。需要利用中间件的异步框架来解决事务完整性及上下文问题。

newkid

yulihua49 发表于 2014-6-5 11:34
广义来说，交易，就是数据加载卸载。
从客户端拿到数据，处理（可能与数据库内的数据有关），然后进入 ...

你又试图来把水搅浑，数据加载卸载指的是“批量”，一般是以大型文件为输入输出的。在线交易都是小而密集的事务。

yulihua49

newkid 发表于 2014-6-5 21:59
你又试图来把水搅浑，数据加载卸载指的是“批量”，一般是以大型文件为输入输出的。在线交易都是小而密集 ...

无论大批量数据吞吐，还是小批量的复杂计算，我都主张在中间件完成，只有小批量简单处理（涉及的数据表多，计算简单的）适合在存储过程做。
最近正在把一个存储过程改出来，它居然在过程里处理XML，巨慢。改出来至少可以提高速度10倍。
还有，比如，已知上车站，下车站，之间没有直达车，为他规划一组路径。这个计算用存储过程是不可想象的。在客户端做也是不可想象的，只有在中间件做。
它涉及大量的时刻表信息（这个信息在一定时间段内是变化的）和复杂的算法。成千上万的客户端不可能都在自己的内存缓冲这个巨大的数据（如果是，又是加载卸载）。
中间件就可以在内存管理这个数据，供所有的客户端使用，算法及复杂检索过程在内存完成。这里涉及加载和更新大数据----还是加载卸载。
这里老是说加载卸载，面太窄了，简单说，高性能的读写持久化数据，高效率的调度系统资源，是中间件的关键技术，没有这个，他就没有生存价值。

实际应用中，OLTP和OLAP是密不可分的。我们站在应用系统的角度看问题，而不是一两个技术点。

newkid

yulihua49 发表于 2014-6-6 09:35
无论大批量数据吞吐，还是小批量的复杂计算，我都主张在中间件完成，只有小批量简单处理（涉及的数据表 ...

ORACLE有完善的XML功能，如果不会用，试图自己解析XML, 那当然是巨慢。用得好的话效率也可以很高，底层也是C实现的。
你这个什么上下车站就是上次说的“清分”吧。早说了这是个伪需求，你们完全可以事先算好，到时只要首尾一匹配就行了，为什么要实时算？

yulihua49

newkid 发表于 2014-6-6 10:01
ORACLE有完善的XML功能，如果不会用，试图自己解析XML, 那当然是巨慢。用得好的话效率也可以很高，底层也 ...

这个行程规划，不是‘清分’，是数年前做的，铁路的，不是地铁的。
规划是交易前行为，清分是交易后行为。

铁路还有一个工作：编组站管理，这个也不适合存储过程。
一列货车，60多辆，进站，进入股道-----加载入库。
每辆车的去向不同，要编制解体计划，在编组场，把不同去向的车分发到不同股道。。。。这涉及到一系列的规定和方法，自动或人机结合的编制算法。
如果出现差错，计算机里的站场与实际场不同  ----  纠正。。。。。。。
这些都是在中间件里处理的。

newkid

yulihua49 发表于 2014-6-6 10:05
这个行程规划是数年前做的铁路的，不是地铁的。

我感觉还是可以预先计算然后直接引用结果。结构可以优化提炼，很多重复的就不必保存了。

yulihua49

newkid 发表于 2014-6-6 10:09
我感觉还是可以预先计算然后直接引用结果。结构可以优化提炼，很多重复的就不必保存了。

全国4000多客运站，每天上千的车次，还有 换乘站，交接时刻。。。。
固定表？疯了。
行程规划，可不是径路计算，还有一个时间维度。

我的意思，实际的交易，情况很多，你不能简单的概括成几种模式，一杆长枪包打天下。。。不是那个时代了。

newkid

yulihua49 发表于 2014-6-6 10:17
全国4000多客运站，每天上千的车次，换乘站，交接时刻。。。。
固定表？疯了。
行程规划，可不是径路计 ...

即使加上时间维度，有意义的路径也不是无限的，不会是你想象的那么多，所以我才说要优化提炼。
当然，如果要考虑是否有票，那就复杂了，但我相信你们没有做这个。

yulihua49

newkid 发表于 2014-6-6 10:34
即使加上时间维度，有意义的路径也不是无限的，不会是你想象的那么多，所以我才说要优化提炼。
当然，如 ...

做了，考虑到余票信息和所需的席别，如卧铺等。
还有客户要求：最快时间，最低票价，上午出发，晚8点前到达等等。
给出的结果也不是一个，而是一堆，大概最多5组，每组15个方案。供客户选择。

不说这么多了，只是说，交易，有复杂的。

所以交易系统的设计者，考虑到用户·需求，选择合适的架构。
还是那句话，我不反对你的观点，但那不是全部。
我也并不是反方，在我们现行的系统里，也大量使用存储过程，中间件，不拒绝存储过程。