对于我开发的一些应用程序(后来就忘了)，我一直在编写纯SQL，主要是针对MySQL的.虽然我在python中使用过ORMs，比如SQLAlchemy，但我并没有坚持多久.通常是文档或复杂性(在我看来)阻碍了我.
我是这样看的:使用ORM实现可移植性，如果只是使用一种数据库，则使用普通SQL.我真的在寻找关于在开发需要数据库支持的应用程序时何时使用ORM或SQL的建议.
考虑一下，与使用ORM相比，只使用轻量级包装器来处理数据库不一致性要好得多.
对于我开发的一些应用程序(后来就忘了)，我一直在编写纯SQL，主要是针对MySQL的.虽然我在python中使用过ORMs，比如SQLAlchemy，但我并没有坚持多久.通常是文档或复杂性(在我看来)阻碍了我.
我是这样看的:使用ORM实现可移植性，如果只是使用一种数据库，则使用普通SQL.我真的在寻找关于在开发需要数据库支持的应用程序时何时使用ORM或SQL的建议.
考虑一下，与使用ORM相比，只使用轻量级包装器来处理数据库不一致性要好得多.
ORMs有一些很好的特性.它们可以处理将数据库列复制到对象字段的大量繁杂工作.它们通常负责将语言的日期和时间类型转换为适当的数据库类型.它们通常通过实例化嵌套对象来非常优雅地处理一对多关系.我发现，如果你在设计数据库时考虑到ORM的优缺点，就可以节省大量进出数据库的工作.(如果你需要映射多态性和多对多关系，你会想知道它是如何处理这些关系的.正是这两个领域提供了大多数"阻抗失配"，因此有人将其称为"计算机科学的越南".)
对于事务性应用程序，例如，您发出请求，获取一些对象，遍历它们以获取一些数据并将其呈现在网页上，性能税很小，在许多情况下，ORM可以更快，因为它会缓存以前看到的对象，否则会多次查询数据库.
对于报告繁重的应用程序，或者每个请求处理大量数据库行的应用程序，ORM税要重得多，它们所做的缓存会变成一个巨大的、无用的内存占用负担.在这种情况下，简单的SQL映射(LinQ或iBatis)或在精简DAL中手工编码的SQL查询就是一种 Select .
我发现，对于任何大型应用程序，您都可以同时使用这两种方法.(ORM用于简单的CRUD，SQL/thin DAL用于报告).