对于我开发的一些应用程序(后来渐渐忘记了)，我一直在编写纯SQL，主要用于MySQL。虽然我在python中使用过orm，比如SQLAlchemy，但我并没有坚持使用它们太久。通常是文档或复杂性(从我的角度来看)阻碍了我。
我是这样认为的:为了可移植性，使用ORM，如果只使用一种类型的数据库，则使用纯SQL。在开发需要数据库支持的应用程序时，我真的在寻找关于何时使用ORM或SQL的建议。
考虑到这一点，使用轻量级包装器来处理数据库不一致要比使用ORM好得多。
当前回答
我想和大家一起回答:“我们有一个中间立场!”
对于应用程序程序员来说，SQL是您可能想要控制的东西和您几乎肯定不想费心控制的东西的混合体。
我一直想要的是一个层(称之为DAL、ORM或microorm，我不介意哪个)，它将负责完全可预测的决策(如何拼写SQL关键字，括号放在哪里，何时创建列别名，为一个包含两个浮点数和一个int的类创建哪些列……)，同时让我负责SQL的高级方面，即如何安排join、服务器端计算、DISTINCTs、GROUP by、标量子查询等。
所以我写了一些这样的东西:http://quince-lib.com/
这是针对c++的:我不知道这是否是你正在使用的语言，但同样的，看看这个“中间地带”的样子可能会很有趣。
其他回答
我开发的一个应用是用python写的IRC机器人。它使用的模块在单独的线程中运行，但我还没有找到一种方法来处理使用sqlite时的线程。不过，这可能是一个单独的问题。
我真的应该把题目和问题都改写一下。我从来没有在任何语言中使用过DAL。
任何值得尊敬的设计都需要对数据库进行一些抽象，以处理阻抗不匹配。但是我认为最简单的第一步(对于大多数情况来说已经足够了)应该是DAL，而不是重量级的ORM。你唯一的选择并不是那些极端的选择。
编辑回复一个要求我描述如何区分DAL和ORM的评论:
DAL是您自己编写的，可能从简单地封装一个表并将其字段映射到属性的类开始。ORM是不需要为从dbms模式的其他属性推断出的抽象机制而编写的代码，主要是pk和fk。(这是您发现自动抽象是否开始出现漏洞的地方。我更喜欢有意地告知他们，但这可能只是我的个人偏好)。
我知道这个问题很老了，但我想我应该在这里发布一个答案，以防有人像我一样遇到这个问题。orm已经走过了很长的路。其中一些实际上为您提供了两全其美的服务:提高开发效率并保持性能。
看看SQL Data (http://sqldata.codeplex.com)。它是c#的一个轻量级ORM，涵盖了所有基础。
供参考，我是SQL数据的作者。
在现代软件开发场景中，是否使用框架是非常常见的难题。
重要的是要理解每个框架或方法都有其优点和缺点——例如，根据我们的经验，我们发现ORM在处理事务时很有用，即插入/更新/删除操作——但当涉及到获取具有复杂结果的数据时，评估ORM工具的性能和有效性就变得重要了。
同样重要的是要理解，选择一个框架或方法并在其中实现所有内容并不是强制性的。我们的意思是，我们可以混合使用ORM和本地查询语言。许多ORM框架在本地SQL中为插件提供扩展点。我们应该尽量不要过度使用一个框架或方法。我们可以结合某些框架或方法，得出适当的解决方案。
当涉及到高并发性的插入、更新、删除和版本控制时，可以使用ORM，还可以使用Native SQL生成报告和长清单
ORM不仅仅是可移植性(就这一点而言，即使使用ORM也很难实现可移植性)。当ORM工具将您从编写模板SQL查询(通过PK或谓词、插入、更新和删除进行选择)中解放出来，并让您专注于问题域时，它基本上为您提供了持久存储之上的抽象层。