最近在用python写支付系统，正在纠结该不该用ORM来限制下
小邮包 包月订购包年程序
下载
小邮包-包月订购包年服务网，该程序由好买卖商城开发，程序采用PHP+MYSQL架设，程序商业模式为目前最为火爆的包月订制包年服务模式，这种包年订购在国外网站已经热火很多年了，并且已经发展到一定规模，像英国的男士用品网站BlackSocks，一年的袜子购买量更是达到了1000万双。功能：1、实现多产品上线，2、不用注册也可以直接下单购买，3、集成目前主流支付接口，4、下单发货均有邮件提醒。
回复内容：
个人经验，各个一开头立志简洁不用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用起来不复杂。手写更复杂。
======
能少些代码，就不要多写。无论如何，这个策略错不了。
