※ 引述《Lordaeron (Terry)》之铭言： : ※ 引述《adrianshum (Alien)》之铭言： : : transaciton based 当然可以这样做. : : 但如果是大家retrieve 同一个 record, 你改了 field A : : 我改了 field B, 你不理会 concurrent update 的话 : : 你改的东西就消失了. 当然你可以自己在 table 再加 sequence : : number 再在 update 前检查一下有没有人在之前 update : : 过, 但这种 optimistic concurrency strategy, 不少 : : OR Mapping framework 已经帮你做了一大部份了, 请问, : : 这是不是有它的价值? : 哇, 有这种状况的话, 也是看你怎麽design 而已. : 如果update sql 只update 你要update 的field, 就无所谓 : concurrency 问题了. 那就是我所谓 transactional based 但我提到的情况在 *实际* 工作上有很多. : 不然你的做法也很 update 前先check sequence, 再query : 回现在的资料, 最combine, 再update 这样吗? combine 等并非必要. 一般 optimistic concurrency strategy 在同时 update, 後 update 者都只是 throw 出 exception 来提醒 data image outdated. 要 merge 要怎样是再之後的事 但至少人家已经帮你做了 date image outdate checking, 你明白价值在哪里吗? : 有没有starvasion 的问题呢? 问题不就搞得比较复杂了? 有复杂吗? 你可以选择 case-by-case 去想怎样handle, 或者自己 再去想一个 mechanism 去 handle. 但framework 提供了 一个 proven way 去解决这样的问题, 除非你的情况很特 殊否则干吗要自己要花时间去设计和写相关的部份? Alien --

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