ORM 试图解决哪些数据库无法解决的问题？
我在一家大型企业的一个由 15 名开发人员组成的团队中工作。我们处理 OLTP 数据库上许多拥有数百万条记录的表。数据仓库数据库要大得多。
我们正在着手开发一个需要开发的新系统，该系统将针对一个非常相似大小的数据库。我们每个人都非常精通 SQL、存储过程等，检查执行计划、定义正确的索引等。我们也非常熟悉 .NET C# 和 ASP.NET。
然而，我们每个人都在独立研究 ORM，但没有人能够理解它们解决的真正问题。相反，我们确实看到的是人们所面临的性能问题以及需要进行的所有调整以适应缺陷。
另一个方面似乎是人们使用 ORM 是为了不必亲自处理数据库和 SQL 等，但事实上，你似乎无法逃避它太久，尤其是当涉及到表现。
所以我的问题是，ORM 解决（或尝试解决）什么问题。
我应该注意到，我们的 OLTP 数据库中有大约 900 个表和 2000 多个存储过程，我们的数据层是根据存储过程自动生成的，并且我们当前使用 ADO.NET 核心。
I work in a team with 15 developers in a large enterprise. We deal with many tables that have millions of records on the OLTP database. The data warehouse database is much larger.
We're embarking on a new system that needs to be developed that will be going against a very similar sized database. Each one of us is highly proficient and very comfortable with SQL, stored procedure etc. examining execution plans, defining the correct indexes etc. We're all also very comfortable in .NET C# and ASP.NET.
However we've each been looking into ORMs independently and none of us is able to understand the real problem they solve. On the contrary, what we do see is the performance issues people have and all the tweaks that need to be done in order to accommodate what the lack.
Another aspect that seems be that people use ORMs so as not to have to get their hands dirty with dealing with the database and SQL etc., but in fact it seems that you can't escape it for too long, especially when it comes to performance.
So my question is, what are the problems ORMs solve (or attempt to solve).
I should note that we have about 900 tables and over 2000 stored procedure in our OLTP database and our data layer is auto generated off of our stored procedures and we use ADO.NET core currently.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
ORM 尝试解决对象关系阻抗不匹配。
也就是说，由于关系数据库本质上是关系型的，因此用于它们的数据建模与 OOP 中使用的建模类型非常不同。
这种差异被称为“对象关系阻抗失配”。 ORM 尝试让您使用 OOP，而不考虑数据库的建模方式。
ORMs attempt to solve the object-relational impedance mismatch.
That is, since relational databases are ... relational in nature, the data modeling used for them is very different from the type of modeling you would use in OOP.
This difference is known as the "object-relational impedance mismatch". ORMs try to let you use OOP without consideration of how the database is modeled.
ORM 适合面向对象的人，他们认为当他们在对象中时一切都会更好地工作。他们在 OO 技能比 SQL 和关系数据库更强、更丰富的项目上有最好的机会。
如果您使用面向对象的语言编写，那么您有时必须处理对象。无论您是否使用 ORM，您都必须将数据从表中取出并放入中间层的对象中，以便可以使用它们。 ORM 可以帮助您解决繁琐的映射工作。但这并不是100%必要的。这是一个像其他选择一样的选择。
不要犯用对象编写客户端/服务器应用程序的错误。如果您的对象只不过是从数据库到客户端的数据载体，我会说您做错了什么。将行为封装在对象中有意义的地方是有价值的。
ORMs are for object-oriented people who think that everything works better when they're in objects. They have their best opportunity on projects where OO skills are stronger and more plentiful than SQL and relational databases.
If you're writing in an object-oriented language you'll have to deal with objects at one time or another. Whether you use ORM or not, you'll have to get that data out of the tables and into objects on the middle tier so you can work with them. ORM can help you with the tedium of mapping. But it's not 100% necessary. It's a choice like any other.
Don't make the mistake of writing a client/server app with objects. If your objects are little more than carriers of data from the database to the client, I'd say you're doing something wrong. There's value in encapsulating behavior in objects where it makes sense.
我认为，与所有这些事情一样，是否应该使用 ORM 问题的答案是“视情况而定”。在很多情况下，人们可能会在后台使用相对较小的数据库编写相对简单的应用程序。
在这些情况下，ORM 很有意义，因为它可以轻松维护（添加列是一个单处更改，使其在您的应用程序中产生影响）和快速周转。
但是，如果您正在处理非常大的数据库和复杂的数据操作，那么 ORM 可能不适合您。也就是说，具有数百万行的表对于 ORM 来说仍然不是问题，这完全取决于您如何返回和使用数据 - 一个结构良好的数据库应该能够提供合理的性能。
在您的情况下，您看不到好处，因为它可能不适合您的应用程序 - 它适用于其他一些应用程序。
顺便说一句 - 您在问题中所描述的 - 用于生成业务层中使用的类的存储过程。这本质上就是一个好的 ORM 映射器 - 摆脱编写样板数据访问代码并处理业务逻辑。
I think, as with all these things, the answer to the question of whether you should use an ORM is 'it depends'. In a lot of cases, people may be writing relatively simple applications with relatively small databases in the background.
In these cases, an ORM makes sense, as it allows for easy maintenance (adding a column is a one place change to have it ripple through you application) and quick turnaround.
However, if you are dealing with very large databases and complex data manipulation, then an ORM is possibly not for you. That said, tables with millions of rows should still not be a problem for an ORM, it all depends on how you return and use the data - a well structured database should allow for reasonable performance.
In you case, you can't see the benefit, as it's maybe not suitable to your application - it is for some others.
BTW - what you describe in your question - stored procedures used to generate classes used in your business layer. This is essentially what a good ORM mapper is - get away from writing the boiler-plate data access code and work on the business logic.
非常好的问题。这取决于您正在构建什么。
如果你有复杂的对象结构（有很多关系的对象和封装的对象），并且在提交事务之前在内存中操作这些对象，那么使用像 Hibernate 这样的 ORM 会容易得多，因为你不需要担心 SQL、Caching、即时对象加载等。作为一个奖励功能，您将获得相当好的数据库独立性。
如果您的应用程序中有非常简单的对象，没有太多功能/方法，您当然可以使用普通的 SQL/DB 连接。不过，无论如何，我建议您使用 ORM，因为您将独立于数据库，更具可移植性，并且当您的系统需要即时对象加载、长事务（带缓存）等时，您将准备好成长
。我一生中使用过许多持久性框架，我会推荐 Hibernate。
Very good question. It depends on what you are building.
If you have complex object structures (objects with many relationships and encapsulated objects) and you manipulate these objects inside memory before committing the transaction, it is much easier to use ORM like Hibernate, because you don't need to worry about SQL, Caching, Just-In-Time object loading, etc. As a bonus feature you will get pretty good database independence.
If you have very simple objects in your application, without much functionality/methods, you can of course use plain SQL/DB connection. However I would recommend you to use ORM anyway, because you will be database independent, more portable and you will be ready to grow, when your system will need just-in-time object loading, long transactions (with caching), etc.
I have worked with many persistence frameworks in my life and I would recommend Hibernate.
简而言之，它真正试图让数据库对程序员来说表现为对象，这样程序员就可以提高工作效率。唯一的好处（除了有助于开发人员的懒惰之外）是映射到类的列是强类型的 - 不再尝试将字符串获取到整数变量中！
从多年来 ORM 库的来来去去来看，它们似乎（恕我直言）只是另一个程序员的玩具。最终，它是另一种抽象，可以在您开始或编写小型应用程序时为您提供帮助。我的观点是，一旦你学会了访问数据库的最佳方式，你不妨继续使用这种方式，而不是学习完成同一任务的多种方法 - 我总是觉得成为专家更有效率，但这可能只是我。
创建和维护映射、生成类等所需的工具是另一个麻烦。在这方面，内置框架（例如 ruby on Rails 的 ActiveRecord 方法）要好得多。
性能可能是一个问题，后端生成的 SQL 也可能是一个问题 - 与您可能编写的小型 SQL 语句相比，使用 ORM 时您几乎总是会获取比所需多得多的数据。
强类型虽然很好，但我会为此赞扬 ORM。
In short, its really trying to make the DB appear as objects to the programmer, so the programmer can be more productive. The only benefit (besides assisting dev laziness) is that the columns mapped to classes are strongly typed - no more trying to fetch a string into an integer variable!
From all the years of ORM libraries that have come and gone, they all seem (IMHO) to be just another programmer toy. Ultimately, its another abstraction that might help you when you start out, or when writing small apps. My opinon here is that once you learn a god way of accessing the DB, you might as well continue to use that way rather than learn many ways of doing the same task - I always feel more productive being a specialist, but that could just be me.
The tools required to create and maintain the mapping, generate the classes, etc are another nuisance. In this regard a built-in framework (eg ruby on rails' ActiveRecord approach) is much better.
Performance can be an issue, as can the sql that is generated at the back end - you will nearly alwas be fetching much more data than you needed when using an ORM compared to the small SQL statements you might otherwise write.
The strong typing is good though, and I would praise ORMs for that.