最近在用python写支付系统，正在纠结该不该用orm来限制下回复内容：
个人经验，各个一开头立志简洁不用orm的项目，随着业务复杂度提高，最后都发展出自己的一套残缺版orm
大的项目还是推荐orm。如果你裸写sql，随着业务和人员的增加你也会试着封装与db连接的模块，那么恭喜你，你自己写了一个orm。
使用 orm 的好处：1. 避免裸写 sql 语句，一个是看起来简洁，另一个是借助 orm 框架防止 sql 注入2. 将 data 抽象为 object，由此可以融入现有的 oo 编程方法缺点：1. 据说 orm 性能不行不过以我自身的姿势水平，还没到考虑 orm 对性能消耗的地步，另外从周围前辈们的经验来看，基本也都推荐使用 orm 作为最佳实践
why not?再说了，object在mvc里还用得上呢对于复杂的逻辑可以自己写sql啊然后让mapper做or映射
一开始决定不用orm的，最终都被逼得自己重新造了个蹩脚的orm轮子；一开始决定使用orm的，最终都被逼得绕开orm自己挽起袖子裸写sql。药丸！
我不用……然后，我创造了轮子……现在我的原则是，后台系统坚决用，挂在前面的网站最好不用。orm要用好不容易，特别很多滥用级联的，本来用json序列化一个对象，结果序列化了一个数据库……所以，当你不知道用不用级联好的时候，那还是最好不要用了……
我觉得稍微大一点的项目，都要用，业务模型一复杂起来，如果随便修改一个东西，我要修改很多处的话，很容易出错。效率问题，sqlalchemy已经为我们做到很好很好了，比我们很多人手写的sql效率都要高。如果确实担心效率问题，你完全可以在常用接口，手写sql，其他还是用orm。至于上面所说的，互联网公司不用，更是扯淡。互联网公司的产品迭代非常快，改动比较多，要是有200个接口，全是用sql写，你很容易就会出错。我目前用flask框架作为http前端，sqlalchemy做orm，twisted用作tcp服务器，twisted方面，基本只访问redis，就是以为twisted本身自带的dbpool基本都手写sql，业务模型稍微一修改，sql语句都要找半天，真是浪费时间。还有上面说的，多个数据库，或者读写分离的，拜托，大哥，这个问题sqlalchemy不知道哪年就解决了。还有缓存问题，我现在基本都用redis作为缓存，基础数据redis里放一份，sql里面放一份，同时更改。常用查询，完全可以自己做一个缓存，这个很难吗？
本来倾向于高效sql，现在人多了开始用简单orm，提高开发效率，解决数据库切换问题。至于性能，可以用缓存。
选用灵活支配sql的orm，谁用谁知道。
不用浪费时间。不如用。sqlalchemy用起来不复杂。手写更复杂。======能少些代码，就不要多写。无论如何，这个策略错不了。