对于我开发的一些应用程序(后来渐渐忘记了),我一直在编写纯SQL,主要用于MySQL。虽然我在python中使用过orm,比如SQLAlchemy,但我并没有坚持使用它们太久。通常是文档或复杂性(从我的角度来看)阻碍了我。

我是这样认为的:为了可移植性,使用ORM,如果只使用一种类型的数据库,则使用纯SQL。在开发需要数据库支持的应用程序时,我真的在寻找关于何时使用ORM或SQL的建议。

考虑到这一点,使用轻量级包装器来处理数据库不一致要比使用ORM好得多。


当前回答

我用纯SQL表示读取,用ORM表示CUD。

性能是我一直关注的问题,尤其是在web应用程序中,但同时也关注代码的可维护性和可读性。为了解决这些问题,我编写了SqlBuilder。

其他回答

没有“一刀切”的解决方案,对于“我是否应该使用an或/m”这个问题也是如此。”。

我会说:如果你必须写一个非常“数据”的应用程序/工具,没有太多的其他逻辑,那么我会使用纯SQL,因为SQL是这类应用程序的领域特定语言。

另一方面,如果我要编写一个包含大量“领域”逻辑的业务/企业应用程序,那么我将编写一个富类模型,它可以在代码中表达这个领域。在这种情况下,OR/M映射器可能会非常有用,因为它可以从您手中省去大量管道代码。

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用于报告)。

我知道这个问题很老了,但我想我应该在这里发布一个答案,以防有人像我一样遇到这个问题。orm已经走过了很长的路。其中一些实际上为您提供了两全其美的服务:提高开发效率并保持性能。

看看SQL Data (http://sqldata.codeplex.com)。它是c#的一个轻量级ORM,涵盖了所有基础。

供参考,我是SQL数据的作者。

使用像SQL一样工作的ORM,但提供编译时检查和类型安全。比如我最喜欢的:数据知识对象(披露:是我写的)

例如:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

完全流。易于设置(不需要定义映射-读取现有模式)。支持连接、事务、内部查询、聚合等。几乎可以用SQL做任何事情。从庞大的数据集(金融时间序列)一直到琐碎的数据集(Android),这一点都得到了证明。

在现代软件开发场景中,是否使用框架是非常常见的难题。

重要的是要理解每个框架或方法都有其优点和缺点——例如,根据我们的经验,我们发现ORM在处理事务时很有用,即插入/更新/删除操作——但当涉及到获取具有复杂结果的数据时,评估ORM工具的性能和有效性就变得重要了。

同样重要的是要理解,选择一个框架或方法并在其中实现所有内容并不是强制性的。我们的意思是,我们可以混合使用ORM和本地查询语言。许多ORM框架在本地SQL中为插件提供扩展点。我们应该尽量不要过度使用一个框架或方法。我们可以结合某些框架或方法,得出适当的解决方案。

当涉及到高并发性的插入、更新、删除和版本控制时,可以使用ORM,还可以使用Native SQL生成报告和长清单