使用的是ORM还是纯SQL? [英] Using an ORM or plain SQL?

问题描述

对于我开发的某些应用程序(后来逐渐忘记了)，我一直在编写纯SQL，主要是针对MySQL.尽管我已经在Python中使用了 SQLAlchemy 之类的ORM，但是我并没有坚持很长时间.通常，这是文档或复杂性(从我的角度来看)阻止了我.

For some of the apps I've developed (then proceeded to forget about), I've been writing plain SQL, primarily for MySQL. Though I have used ORMs in python like SQLAlchemy, I didn't stick with them for long. Usually it was either the documentation or complexity (from my point of view) holding me back.

我这样看:如果要使用一种类型的数据库，则使用ORM进行可移植性，使用普通SQL.我真的在寻求有关在开发需要数据库支持的应用程序时何时使用ORM或SQL的建议.

I see it like this: use an ORM for portability, plain SQL if it's just going to be using one type of database. I'm really looking for advice on when to use an ORM or SQL when developing an app that needs database support.

考虑一下，与使用ORM相比，仅使用轻量级包装器来处理数据库不一致要好得多.

Thinking about it, it would be far better to just use a lightweight wrapper to handle database inconsistencies vs. using an ORM.

推荐答案

ORM具有一些不错的功能.他们可以处理将数据库列复制到对象字段的繁琐工作.他们通常负责将语言的日期和时间类型转换为适当的数据库类型.它们通常还可以通过实例化嵌套对象来相当优雅地处理一对多关系.我发现如果您在设计数据库时考虑到了ORM的优点和缺点，那么在将数据移入或移出数据库时可以节省很多工作. (如果需要映射它们，您将想知道它如何处理多态性和多对多关系.正是这两个域提供了大多数阻抗不匹配"，这使某些人将ORM称为计算机科学的越南". )

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可以更快，因为它会缓存以前看到的对象，否则将多次查询数据库.

For applications that are transactional, i.e. you make a request, get some objects, traverse them to get some data and render it on a Web page, the performance tax is small, and in many cases ORM can be faster because it will cache objects it's seen before, that otherwise would have queried the database multiple times.

对于报表繁重的应用程序，或每个请求处理大量数据库行的应用程序，ORM税要重得多，并且它们所做的缓存会变成很大的无用的内存消耗负担.在这种情况下，简单的SQL映射(LinQ或iBatis)或精简DAL中的手工编码SQL查询就是解决之道.

For applications that are reporting-heavy, or deal with a large number of database rows per request, the ORM tax is much heavier, and the caching that they do turns into a big, useless memory-hogging burden. In that case, simple SQL mapping (LinQ or iBatis) or hand-coded SQL queries in a thin DAL is the way to go.

对于任何大型应用程序，我都发现您会同时使用这两种方法. (ORM用于简单的CRUD，而SQL/Thin DAL用于报告).

I've found for any large-scale application you'll find yourself using both approaches. (ORM for straightforward CRUD and SQL/thin DAL for reporting).

这篇关于使用的是ORM还是纯SQL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！