※ 引述《adrianshum (Alien)》之铭言： : 问题在於 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 对 : 於架构和设计上的好处就不说了) 之前已经提过，SP应该避免把不必要的逻辑放进来，如果一个逻辑 能复杂到消耗过多的cpu cycle或是memory，基本上要被归类到不必 要的逻辑去。 要提到scalability，原则上要视每个case而定，有的时候逻辑放在 SP反而能够scale，你举得batch processing是一个例子，其他像是 减少不必要的大量资料回传到APP、有hot table/block的情况、或是 减低lock contention时，把(部份)逻辑放在SP反而是对scalability 有帮助。 在performance上，使用SP有很大的优势，在scalability上，并没有 一定，要依各个case而定。 --

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