对于我开发的一些应用程序(后来渐渐忘记了)，我一直在编写纯SQL，主要用于MySQL。虽然我在python中使用过orm，比如SQLAlchemy，但我并没有坚持使用它们太久。通常是文档或复杂性(从我的角度来看)阻碍了我。
我是这样认为的:为了可移植性，使用ORM，如果只使用一种类型的数据库，则使用纯SQL。在开发需要数据库支持的应用程序时，我真的在寻找关于何时使用ORM或SQL的建议。
考虑到这一点，使用轻量级包装器来处理数据库不一致要比使用ORM好得多。
当前回答
我开发的一个应用是用python写的IRC机器人。它使用的模块在单独的线程中运行，但我还没有找到一种方法来处理使用sqlite时的线程。不过，这可能是一个单独的问题。
我真的应该把题目和问题都改写一下。我从来没有在任何语言中使用过DAL。
其他回答
任何值得尊敬的设计都需要对数据库进行一些抽象，以处理阻抗不匹配。但是我认为最简单的第一步(对于大多数情况来说已经足够了)应该是DAL，而不是重量级的ORM。你唯一的选择并不是那些极端的选择。
编辑回复一个要求我描述如何区分DAL和ORM的评论:
DAL是您自己编写的，可能从简单地封装一个表并将其字段映射到属性的类开始。ORM是不需要为从dbms模式的其他属性推断出的抽象机制而编写的代码，主要是pk和fk。(这是您发现自动抽象是否开始出现漏洞的地方。我更喜欢有意地告知他们，但这可能只是我的个人偏好)。
ORMs have some nice features. They can handle much of the dog-work of copying database columns to object fields. They usually handle converting the language's date and time types to the appropriate database type. They generally handle one-to-many relationships pretty elegantly as well by instantiating nested objects. I've found if you design your database with the strengths and weaknesses of the ORM in mind, it saves a lot of work in getting data in and out of the database. (You'll want to know how it handles polymorphism and many-to-many relationships if you need to map those. It's these two domains that provide most of the 'impedance mismatch' that makes some call ORM the 'vietnam of computer science'.)
对于事务性应用程序，即您发出请求，获取一些对象，遍历它们以获得一些数据并在Web页面上呈现，性能损失很小，并且在许多情况下ORM可以更快，因为它将缓存以前见过的对象，否则将多次查询数据库。
对于报告量大的应用程序，或者每个请求都要处理大量的数据库行，ORM税要重得多，它们所做的缓存变成了一个巨大的、无用的内存占用负担。在这种情况下，可以使用简单的SQL映射(LinQ或iBatis)或在瘦DAL中手工编写SQL查询。
我发现，对于任何大型应用程序，您都会发现自己同时使用这两种方法。(ORM用于直接的CRUD, SQL/thin DAL用于报告)。
我用纯SQL表示读取，用ORM表示CUD。
性能是我一直关注的问题，尤其是在web应用程序中，但同时也关注代码的可维护性和可读性。为了解决这些问题，我编写了SqlBuilder。
没有“一刀切”的解决方案，对于“我是否应该使用an或/m”这个问题也是如此。”。
我会说:如果你必须写一个非常“数据”的应用程序/工具，没有太多的其他逻辑，那么我会使用纯SQL，因为SQL是这类应用程序的领域特定语言。
另一方面，如果我要编写一个包含大量“领域”逻辑的业务/企业应用程序，那么我将编写一个富类模型，它可以在代码中表达这个领域。在这种情况下，OR/M映射器可能会非常有用，因为它可以从您手中省去大量管道代码。
ORM不仅仅是可移植性(就这一点而言，即使使用ORM也很难实现可移植性)。当ORM工具将您从编写模板SQL查询(通过PK或谓词、插入、更新和删除进行选择)中解放出来，并让您专注于问题域时，它基本上为您提供了持久存储之上的抽象层。