※ 引述《FireLake (XXX)》之铭言： : ※ 引述《JoeHorn (每天都在公司玩OLG)》之铭言： : : 一个 DB connection 可以执行很多次 SQL statements， : : 你举的这个例子只需要 transaction，但是.. 可以用同一个 connection。 : : 更何况，很多程式语言有 connection pool 管理能力。 : : （因为可以用同一个 connection，以下我就不回了.. 因为都不是考量因素） : 这部份完全没有解释performance上的问题，用不用 connection pool 都 : 一样。 : 一个 DB connection 的确是可以执行好几个SQL，但要注意到的是每执行 : 一个SQL就是一次从client到server的 round trip。重复使用同一个 DB : connection 或是用 connetion pool 只能省下 login, authetication, : 和一些 initialization 的时间，但是执行每一个 SQL，还是需要从 client/ : application 把 sql statement 或是 binding variable 的值传到 : server/db (当已有curosr时)。此外，执行完後 server/db 还要把结果传 : 回去。这不只是传输时间而已，处理每一个 SQL 时，database要花时间在 : 解析sql statement、处理cursor、binding variable、重新取得lock上面， : 非常没有效率。 : 用个简单的例子，现在有10个SQL要执行，就叫做 SQL 1 到 SQL 10 好了， : SQL 10 要依据 SQL 9 的结果，SQL 9 要依据SQL 8 的结果，以此类推。用 : stored procedure 只要一个 round trip，不用的话就要10次，这在效能上 : 有很大的差别，而且如果其中有几个SQL要传回大量的资料，不用 stored : procedure 的效能会是最糟糕。 : 把 logic 放在 stored procedure 或是 application 各有利弊，但在 : performance 上，使用 stored procedure 有很大的优势。 对一半 一般来说 performance 当然直接用 SP 比较好. 如你所说, 省了 round trip 就差很远了. 问题在於 scalability. DB 相比起 app server, scalability 不可同日而语. 你的系统可能用 SP, 应付一百人没问题, 但要应付一 千人, DB 机器的 CPU, memory 都花在 biz logic 上, 你要找一部更强的 DB 并不是想那麽容易, 价钱也可以 吓你一大跳. 同样能应付一百人份量的复杂 SP 的 DB, 单用来作简 单的CRUD operation, biz logic 移回 app server, DB 应付一千人份量的 simple CRUD 说不定也绰绰有余. 一般作为 transactional 类型的 application, 要应付 多一些 user, 差不多按比例加 app server 数类就行了. (DB 可不是简单加 server 就能应付更多 user) 当然不能一刀切. 有些大量资料的处理, 比如 batch processing 之类, 把部份东西放回 SP 做也是蛮正常 的做法. (这类单谈 performance/scalability, multi-tier 对 於架构和设计上的好处就不说了) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.238.156.185