ORM Haters Don’t Get It
I’ve seen tons of articles and comments (especially comments) that tell us how bad, crappy and wrong is the concept of ORM (object-relational mapping). Here are the usual claims, and my comments to them:
- “they are slow” – there is some overhead in mapping, but it is nothing serious. Chances are you will have much slower pieces of code.
- “they generate bad queries which hurts performance” – first, it generates better queries than the regular developer would write, and second – it generates bad queries if you use bad mappings
- “they deprive you of control” – you are free to execute native queries
- “you don’t need them, plain SQL and XDBC is fine” – no, but I’ll discuss this in the next paragraph
- “they force you to have getters and setters which is bad” – your entities are simple value objects, and having setters/getters is fine there. More on this below
- “database upgrade is hard” – there are a lot of tools around the ORMs that make schema transition easy. Many ORMs have these tools built-in
But why do you need an ORM in the first place? Assume you decided not to use one. You write your query and get the result back, in the form of a ResultSet (or whatever it looks like in the language you use). There you can access each column by its name. The result is a type unsafe map-like structure. But the rest of your system requires objects – your front-end components take objects, your service methods need objects as parameters, etc. These objects are simple value-objects, and exposing their state via getters is nothing wrong. They don’t have any logic that operates on their state, they are just used to transfer that state. If you are using a statically-typed language, you are most likely using objects rather than type-unsafe structures around your code, not to mention that these structures are database-access interfaces, and you wouldn’t have them in your front-end code. So then a brilliant idea comes to your mind – “I will create a value object and transfer everything from the result set to it. Now I have the data in an object, and I don’t need database-access specific interfaces to pass around in my code”. That’s a great step. But soon you realize that this is a repetitive task – you are creating a new object and manually, field by field, transferring the result from your SQL query to that object. And you devise some clever reflection utility that reads the object fields, assumes you have the same column names in the DB, reads the result set and populates the object. Well, guess what – ORMs have been doing the same thing for years and years now. I bet theirs are better and work in many scenarios that you don’t suspect you’ll need. (And I will just scratch the surface of how odd is the process of maintaining native queries – some put them in one huge text file (ugly), others put them inline (how can the DBAs optimize them now?))
To summarize the previous paragraph – you will create some sort of ORM in your project, but yours will suck more than anything out there, and you won’t admit it’s ORM.
This is a good place to mention an utility called commons-dbutils (Java). It is a simple tool to map database results to objects that covers the basic cases. It is not an ORM, but it does what an ORM does – maps the database to your objects. But there’s something missing in the basic column-to-field mapper, and that’s foreign keys and joins. With an ORM you can get the User’s address in an Address field even though a JOIN would be required to fetch it. That’s both a strength and a major weakness of ORMs. The *ToOne mappings are generally safe. But *ToMany collections can be very tricky, and they are very often misused. This is partly the fault of ORMs as they don’t warn you in any way about the consequences of mapping a collection of, say, all orders belonging to a company. You will never and must never need to access that collection, but you can map it. This is an argument I’ve never heard from ORM haters, because they didn’t get to this point.
So, are ORMs basically dbutils plus the evil and risky collection mapping? No, it gives you many extras, that you need. Dialects – you write your code in a database-agnostic way, and although you are probably not going to change your initially selected database vendor, it is much easier to use any database without every developer learning the culprits if its syntax. I’ve worked with MSSQL and Oracle, and I barely felt the pain in working with them. Another very, very important thing is caching. Would you execute the same query twice? I guess no, but if it happens to be in two separate methods invoked by a third method, it might be hard to catch, or hard to avoid. Here comes the session caching, and it saves you all duplicated queries to get some row (object) from the database. There is one more criticism to ORMs here – the session management is too complicated. I have mainly used JPA, so I can’t tell about others, but it is really tricky to get the session management right. It is all for very good reasons (the aforementioned cache, transaction management, lazy mappings, etc.), but it is still too complicated. You would need at least one person on the team that has a lot of experience with a particular ORM to set it up right.
But there’s also the 2nd level cache, which is significantly more important. This sort of thing is what allows services like facebook and twitter to exist – you stuff your rarely-changing data in (distributed) memory and instead of querying the database every time, you get the object from memory, which is many times faster. Why is this related to ORMs? Because the caching solution can usually be plugged into the ORM and you can store the very same objects that the ORM generated, in memory. This way caching becomes completely transparent to your database-access code, which keeps it simple and yet performant.
So, to summarize – ORMs are doing what you would need to do anyway, but it is almost certain that a framework that’s been around for 10 years is better than your homegrown mapper, and they are providing a lot of necessary and important extras on top of their core functionality. They also have two weak points (they both practically say “you need to know what you are doing”):
- they are easy to misuse, which can lead to fetching huge, unnecessary results from the database. You can very easily create a crappy mapping which can slow down your application. Of course, it is your responsibility to have a good mapping, but ORMs don’t really give you a hand there
- their session management is complicated, and although it is for very good reasons, it may require a very experienced person on the team to set things up properly
I’ve never seen these two being used as arguments against ORMs, whereas the wrong ones in the beginning of this article are used a lot, which leads me to believe that people raging against ORMs rarely know what they are talking about.
I’ve seen tons of articles and comments (especially comments) that tell us how bad, crappy and wrong is the concept of ORM (object-relational mapping). Here are the usual claims, and my comments to them:
- “they are slow” – there is some overhead in mapping, but it is nothing serious. Chances are you will have much slower pieces of code.
- “they generate bad queries which hurts performance” – first, it generates better queries than the regular developer would write, and second – it generates bad queries if you use bad mappings
- “they deprive you of control” – you are free to execute native queries
- “you don’t need them, plain SQL and XDBC is fine” – no, but I’ll discuss this in the next paragraph
- “they force you to have getters and setters which is bad” – your entities are simple value objects, and having setters/getters is fine there. More on this below
- “database upgrade is hard” – there are a lot of tools around the ORMs that make schema transition easy. Many ORMs have these tools built-in
But why do you need an ORM in the first place? Assume you decided not to use one. You write your query and get the result back, in the form of a ResultSet (or whatever it looks like in the language you use). There you can access each column by its name. The result is a type unsafe map-like structure. But the rest of your system requires objects – your front-end components take objects, your service methods need objects as parameters, etc. These objects are simple value-objects, and exposing their state via getters is nothing wrong. They don’t have any logic that operates on their state, they are just used to transfer that state. If you are using a statically-typed language, you are most likely using objects rather than type-unsafe structures around your code, not to mention that these structures are database-access interfaces, and you wouldn’t have them in your front-end code. So then a brilliant idea comes to your mind – “I will create a value object and transfer everything from the result set to it. Now I have the data in an object, and I don’t need database-access specific interfaces to pass around in my code”. That’s a great step. But soon you realize that this is a repetitive task – you are creating a new object and manually, field by field, transferring the result from your SQL query to that object. And you devise some clever reflection utility that reads the object fields, assumes you have the same column names in the DB, reads the result set and populates the object. Well, guess what – ORMs have been doing the same thing for years and years now. I bet theirs are better and work in many scenarios that you don’t suspect you’ll need. (And I will just scratch the surface of how odd is the process of maintaining native queries – some put them in one huge text file (ugly), others put them inline (how can the DBAs optimize them now?))
To summarize the previous paragraph – you will create some sort of ORM in your project, but yours will suck more than anything out there, and you won’t admit it’s ORM.
This is a good place to mention an utility called commons-dbutils (Java). It is a simple tool to map database results to objects that covers the basic cases. It is not an ORM, but it does what an ORM does – maps the database to your objects. But there’s something missing in the basic column-to-field mapper, and that’s foreign keys and joins. With an ORM you can get the User’s address in an Address field even though a JOIN would be required to fetch it. That’s both a strength and a major weakness of ORMs. The *ToOne mappings are generally safe. But *ToMany collections can be very tricky, and they are very often misused. This is partly the fault of ORMs as they don’t warn you in any way about the consequences of mapping a collection of, say, all orders belonging to a company. You will never and must never need to access that collection, but you can map it. This is an argument I’ve never heard from ORM haters, because they didn’t get to this point.
So, are ORMs basically dbutils plus the evil and risky collection mapping? No, it gives you many extras, that you need. Dialects – you write your code in a database-agnostic way, and although you are probably not going to change your initially selected database vendor, it is much easier to use any database without every developer learning the culprits if its syntax. I’ve worked with MSSQL and Oracle, and I barely felt the pain in working with them. Another very, very important thing is caching. Would you execute the same query twice? I guess no, but if it happens to be in two separate methods invoked by a third method, it might be hard to catch, or hard to avoid. Here comes the session caching, and it saves you all duplicated queries to get some row (object) from the database. There is one more criticism to ORMs here – the session management is too complicated. I have mainly used JPA, so I can’t tell about others, but it is really tricky to get the session management right. It is all for very good reasons (the aforementioned cache, transaction management, lazy mappings, etc.), but it is still too complicated. You would need at least one person on the team that has a lot of experience with a particular ORM to set it up right.
But there’s also the 2nd level cache, which is significantly more important. This sort of thing is what allows services like facebook and twitter to exist – you stuff your rarely-changing data in (distributed) memory and instead of querying the database every time, you get the object from memory, which is many times faster. Why is this related to ORMs? Because the caching solution can usually be plugged into the ORM and you can store the very same objects that the ORM generated, in memory. This way caching becomes completely transparent to your database-access code, which keeps it simple and yet performant.
So, to summarize – ORMs are doing what you would need to do anyway, but it is almost certain that a framework that’s been around for 10 years is better than your homegrown mapper, and they are providing a lot of necessary and important extras on top of their core functionality. They also have two weak points (they both practically say “you need to know what you are doing”):
- they are easy to misuse, which can lead to fetching huge, unnecessary results from the database. You can very easily create a crappy mapping which can slow down your application. Of course, it is your responsibility to have a good mapping, but ORMs don’t really give you a hand there
- their session management is complicated, and although it is for very good reasons, it may require a very experienced person on the team to set things up properly
I’ve never seen these two being used as arguments against ORMs, whereas the wrong ones in the beginning of this article are used a lot, which leads me to believe that people raging against ORMs rarely know what they are talking about.
ORMs do stuff I don’t need them to do, like change tracking, identity management and lazy loading. In the end is about how much stuff you want/need a tool to do for you. And some Micro-ORMs out there are much faster.
Full disclosure, I dislike ORMs. I like to use store serialized protocol buffers directly in a Blob column of the database, and use the extra columns for indexing purposes only.
It is definitely not as powerful as an ORM, but I like the simplification. It is a type-safe approach however, and is resilient to protobuf schema changes.
I’m curious to hear your thought about this style.
One limitation I’ve found for ORMs like Hibernate is in reporting.
For almost anything non trivial you’ll probably need to use native queries to obtain the exact results you’re looking for which kind of defeats the purpose of using an ORM. In my experience this happens a lot.
Is JDBC or the likes an option?
===============================
Not really! As you pointed out JDBC API is clumsy and you need to do a lot of DTO management.
The middle road
===============
Personally I’m quite found of MyBatis:
– I can write my sql nicely in xml files (or annotations if I want); This sql I can easily test in my DB tool of choice.
– If my tables names (or result aliases) match my domain model fields I get automatic mapping
– Supports *toMany mappings
– really fast learning curve. I’ve picked up MyBatis within a day.
– build in caching or via plugins
Downsides
———
– MyBatis works well only if you like to design your DB first. Since data always outlives the application I firmly believe a good database design is crucial.
– prototyping is slow; This can be alleviated up to some point by using MyBatis Generator
Prototyping is slow due to
Where’s the edit button? 🙁
Good post!
I also prefer MyBatis in some use cases. However, ORM is a good tool and helps in many situations to reduce effort.
I would never ever use just SQL / JDBC or even Spring’s JdbcTemplate, if there are more than two or three queries to write…
@Jacob Groundwater
If you do this, you should not be using a relational database in the first place, and the whole ORM argument goes away. Some NoSQL store would suit you more.
Full disclosure, I develop an ORM for a living.
Handling data is important. And it’s quite complex. The bad rep of most ORMs usually comes from people who didn’t spend enough time learning how to use it.
It is a complex domain and you should better know what you are doing. There isn’t a tool out there that can save you from negligence.
There are two kinds of ORM tools. One is the complex, enterprisey, bloated with features, never leave the designer kind of ORM and the other one is a robust implementation of a mapper. I assume you are talking for the first one, it is also the kind of ORM I am working on.
These tools usually come with a lot of hype and a lot of features, that people usually don’t understand. I cannot express how many customer solutions I’ve saw that did the wrong thing the wrong way. Developers need to wake up and realize it’s all about the DATA, and you can’t expect to plug in a 3rd party ORM to work out of the box.
Actually I urge everybody to go ahead and implement it on their own. Use stored procedures, write your own queries, suffer and learn from the experience. Once you have faced and solved the issues of data management, see how an ORM can help, look at the best practices then and (maybe) only then, will you be able to take the most of such a tool.
My advice: don’t overuse the ORM, use for the things you are comfortable with and things you know work.
Sidenote: Something everybody does wrong is inheritance. The object/conceptual model allows for inheritance, however the relational/database one does not. What has happened is that every ORM out there has a different (and usually not optimal) implementation and as soon as you start using this shit hits the fan. Big time. Don’t use it.
You mentioned the “you don’t need them, plain SQL or xDBC is fine” argument but didn’t go into it in detail.
I’ve heard that argument before, and it’s exactly the same as the old “why do we need a higher-level programming language, it can never be as efficient as programming in assembly language” argument. Programming with JDBC is like programming in assembly language – it’s a lot of tedious work, it’s very platform-specific (despite the fact that JDBC tries to provide a common interface for all brands of databases) and it’s hard to maintain. And, exactly as you describe, you’ll find yourself building a simplistic mini-ORM someday.
I don’t see what is wrong with using ORM for the trivial work and downgrade to raw SQL when you hit a performance bottleneck or your ORM just can’t handle a complex scenario. Even if you hit the problem because you are not good with the ORM then still it should not be a problem because you can always downgrade but you have the endless simple reads with just a filter or paging handled for you and this is a lot of work.
I think that perhaps ORMs are a statically typed language thing, or perhaps a “Java-like” language thing.
If you’re using a powerful functional language, which has lots of great primitives for processesing sets and maps, then an ORM is probably not all that useful as doing relational and functional programming on straight database output is trivial.
There’s no Clojure ORM to my knowledge, and I’ve never heard of a Haskell ORM. These are tools for statically typed OOP languages like Java and C#.
I’ve used DBIx::Class in Perl, and while its perhaps one of the best ORMs out there, I’m not even sure even its worth using. There’s a huge learning curve, and after you’ve mastered it you really don’t save yourself that much hassle over just writing libraries containing straight SQL. Its more portable than straight SQL, but that’s about all you get.
So even in languages like Perl, which isn’t that exotic, ORMs probably aren’t really that smart a choice.
I think I’ve started to dislike ORM for the two reasons you said: it’s very easy to misuse and uses a very complicated session management scheme (not to say other things).
Someone said above that it’s all about data, and I can’t agree more! You have all these business problems you need to solve, and yet you have to stop everything and study very hard to understand all the intertwined concerns that affect how you are accessing your data.
I’ve been using ORM in my latest projects, trying to keep the app database-agnostic and all that, but lately I’ve been thinking that maybe I would be better off choosing a database platform (PostgreSQL in my mind) and going all for it…
I can see that many people find it complicated and complain about the wrong reasons, but maybe that’s all related to the problem that you said, in that it’s easy to misuse. I would add easy to misunderstand, but I guess it’s about the same thing.
Cheers!
Elias
@Max Toro: Ever used Hibernate’s StatelessSession?
@Jacob Groundwater: All the people, who don’t use Java, will probably don’t like you too much for this approach. Code comes and goes, but the data will stay and you store it in a language-specific way.
@Elias: As Stilgar pointed out, that’s when an explicit data access layer pays off, because you should be able to transparently substitute a JPA DAO with a JDBC DAO any time.
This is actually something I haven’t seen with any ORM yet: The ability to replace a JPQL or HQL query with a native one depending on the dialect, e.g. “for this type of database use this native query here in place of that generic query there”. Would be very helpful for DB-specific optimisation.
You failed to list the single most important argument against ORM.
Hierarchies, and Sets are fundamentally different things, and this creates an impedance mismatch that is fundamentally difficult to resolve when translating from one to the other.
This isn’t to say that ORMs aren’t useful, only that one should be aware of this mismatch when trying to translate data and functions from one domain to another.
I don’t like ORMs, but I use them, when I have good reasons to use them, because they can do a fantastic job.
BUT, they also can be chosen for bad reasons. For instance, one of my customer wanted to use Hibernate because he didn’t want to manage the DB. Most of the developers were Java developers with no knowledge of DB.
So, they decide to ignore the DB, and use Hibernate to hide it.
And guess what ? The default generated schema is a mess.
Of course, the issue here is the people, not the ORM.
But ORM can give the impression to known nothing about DB and be able to handle it.
There need to be specific development rules when an ORM is used : DB schema review, DB queries review …
With a team of experienced people, ORM usage is a pleasure. With a team of beginners, it can be very painfull.
“But *ToMany collections can be very tricky, and they are very often misused. This is partly the fault of ORMs as they don’t warn you in any way about the consequences of mapping a collection of, say, all orders belonging to a company. You will never and must never need to access that collection”
Where is the problem ? The problem, in this case, is by misused , not an ORM issue.
For me, a big problem using ORM is they generate enhanced classes and serialization can be a problem
Very well said, I would prefer to have a library with little bit of bugs instead of letting developers re-invent the same things on their own and end up creating a disaster.
Many apps, which do not use ORM like frameworks struggle in performance since not everyone know how to write best performance queries.
Also there is a high chance that ORM tool would generate a better or equivalent query to average sql coder.
I have seen many old projects which did not use ORMs tend to create their own at the later stage and then have nightmare moving away from them.
Well Bozho I’m going to have to disagree. You state that if I choose to write an ORM, it will “suck”. Wouldn’t this also hold true for the authors of the many popular ORMs already in use? Or do these developers have some special knowledge of the dark arts that allows their code to be magically good and mine to “suck”?
It’s true many custom built ORMs do suck but I make the argument that this is due to a lack of experience on the developer’s behalf and that no ORM is going to compensate for someone that doesn’t have the skills required to build a decent database with decent SQL. If you can’t trust your developers to write a proper and simple ORM then I suggest you get better developers rather than installing an ORM.
First, writing a good ORM is tricky. I don’t think any developer out there can do it right. I’m not even sure I would be able to do it right if I hadn’t seen many other ORMs.
Second, it’s about focus – your focus is to make a business application, not an ORM. The ORM is just a building block, and you can’t be working full-time on the ORM. That was not the case for existing ORMs.
And third, existing ORMs have been out there for ages – major bugs and problems have been addressed and fixed. Your new ORM is likely to suffer from many of these bugs, until it becomes mature.
I am entirely for using ORMs. I just don’t believe it’s reasonable to use them 100% of the time.
For me the biggest disadvantage of an ORM is that
* it produces hard to read SQL
* it hides major features of the database like creating temporary tables which are awesome for improving performance of complex queries (hundreds of lines of SQL)
These points make difficult the life of a person who is not a developer but is tasked with writing/optimizing/debugging queries based on some complex business requirements. Being able to execute hand-written native SQL queries shines in this situation. And no – createNativeQuery() is not the solution because it only executes a single SQL query.
That being said, ORMs are great for everything else.
Finally I am curious about your main argument. It seems like a very wild guess that everyone is eventually going to implement his own silly ORM. I’ve seen many project where people were successfully using plain xDBC and never looked to implement/use any kind of ORM.
I don’t create a comment, but after browsing some of the comments here Bozho’s tech blog » ORM Haters Don’t Get It.
I do have some questions for you if you don’t mind.
Could it be only me or do some of these responses look like
they are left by brain dead visitors? 😛
And, if you are writing on additional places, I would like to follow you.
Could you list of the complete urls of all your public sites like your twitter feed, Facebook page or linkedin profile?
I believe that is one of the most significant info for me.
And i’m happy reading your article. However wanna commentary on some normal things, The web site taste is wonderful,
the articles is truly excellent : D. Excellent job, cheers
I’ll immediately grasp your rss as I can not find your
e-mail subscription hyperlink or newsletter service.
Do you have any? Kindly let me realize so that I may just subscribe.
Thanks.
Look into my site; belt drive garage door opener
Today, I went to the beachfront with my children.
I found a sea shell and gave it to my 4 year old daughter and said “You can hear the ocean if you put this to your ear.” She put the shell to her
ear and screamed. There was a hermit crab inside and it pinched her ear.
She never wants to go back! LoL I know this
is entirely off topic but I had to tell someone!
マンハッタンポーテージ メッセンジャーバッグ
It’s not off topic:
The shell was an ORM.
You were an OOP evangelist.
The sound of the sea was the empty promises of OOP evangelists.
Your daughter was an applications developer.
The hermit crab was the truth!
All,
Nice to read some argumentation which in essence ignores some points.
When using third-party ORM-tools, you add an additional dependency in your product, which could leave you exposed to additional life-cycles of your application, just to solve some workarounds or implement new features or in case of commercial products, just to be able to get support on your contract when(heaven forbid) something goes wrong.
I mostly see no reason in using them exept some specific scenarios, but in the end a company or client’s requirements are mostly different. They just want an application that is supportable over x years. And if you have a release every 6 months of your ORM-tool, most likley as a customer your paying every time to reimplement the new framework. I’ve seen it happen time over time.
So in the past I’ve change my strategy, and to be honest we all were enthousiastic, driven developers that always want to use the newest thing in a project. Nothing has changed over the years, and nothing is wrong with that, it’s called learning.
Nowadays I use something you could call a lightweight ORM, but in the end just helps to give some structure to the developer to resolve the impedance mismatch.
Mostly just based on code reuse, which allowed me through it’s simplicity to get complete teams without prior knowledge up and running under 4 hours.
Last week I did a challenge with one of those advocates of using ORM mappers. We had a database design, and we just implemented as fast as possible the datalayer.
By the time he was finished configuring his framework, my work was already done for some time!
In the end, I’ve watched numerous frameworks to claim increased ROI, developer efficiency etc.
but always the ROI was seldom proven…
But do you always need an ORM?
I whether I map from a table using a method that goes from ResultSet -> MyClass, annotations from Hibernate, etc. it would still boil down to the same thing, right?
I don’t mind doing it manually for small applications.
SQL is not a difficult language, and if I have to join, then I just… join.
All I end up doing is having a TypeDao for every type I need, and add on methods to them for everything I need to do.
So I’d have a UserDao with the method getUsersFromDepartment(Department dept), returning a collection of users.
Whether or not there’s Hibernate under there or not, is of zero consequence to the caller.
And it’s not very hard to set this stuff up either. So I feel I have to ask, at what point does the gain outweigh the pain?
ORM is much slower. It benefits developers who are weak at SQL at the cost of performance. An absolutely appalling idea in the development process.
SQL is orders of magnitude faster than ORM.
That’s such a general comment it almost doesn’t mean anything. ORM is not slower if it generates the right queries, and that depends on the user of the ORM as well as the ORM.
So, you don’t want any external dependency. Then you must implement your own version of the JVM. But why stop here? Create your own Linux distribution too. Even then you’re dependent of hardware vendors, so if you are serious in this path you must begin building your very own chips.
May be your team can setup very fast the enviroment with your home made ORM, wich surely is tailored upon certain dababase structure style (naming conventions, for example). On the other side, enterprise ORM have to be used not only in your specific use case, but in a much wider spectrum of scenarios, so you need to spend more time configuring them. There are enterprise ORM with sensible defaults that covers most of the usage scenarios.
great and nice post applicable
ORM has so many problems that better is to avoid to use it at whole. And list of these problems in super-long. But I will point out only 2 notes – usually forgotten by developers and ORMs lovers:
1. ORM lovers should look at generated SQL as often as possible, and to compare it with human-written SQL. You will be very surprised how often resulting SQL is super-inefficient, stupid, naive and complex. It totally ignores absolutely obvious solutions which any DB developer knows as well as dialect features
2. This is most important note: SQL was invented to be max. human readable DSL. Today most young programmers and students even try to create a lot of… EDSLs in programming language to be used instead of SQL. Are you feeling how it’s stupid? 🙂 You can compare how looks the same “query” from lists in Haskell, for example. It’s puzzle-like and crappy. 2 joins, one ordering and where becomes absolutely unreadable sh*t of operators and combinators. We, programmers, want to have declarative, human readable and clean language – it was invented already, it’s called SQL 🙂 Today we have about 60 years history of programming languages. And they are so stupid and try to repeat and repeat and repeat the same things that communication with SQL is super big problem for them. Why people invent numerous programming language? To repeat the same what was done 30-40 years ago? I know only one language/platform which developers understand this problem and offer some kind of solution – it’s .NET and LINQ. All other inventors of the next wheel (ORMs) – will be better to stop littering IT industry with their buggy hand-made articles 😉
> ORM is not slower if it generates the right queries, and that depends on the user of the ORM as well as the ORM.
Absolutely! This will be done, when we will use AI in the ORMs which will wite SQL. AI – is the best SQL generator! But… there is already such generator! It’s – me 🙂 So, why I need another SQL generator?! 🙂
ORMs have been invented by programmers who don’t understand what a DB is and what it offers. They are one the most stupid things that happened to the industry.
SQL and stored procedure are the way to manage DBs and to get what you need in an optimal way. Fetch data, store them in some fancy object with some mappers, and that’s it.
Using ORM is reinventing the wheel, it’s like buying a Ferrari, throw aways its engine and replace it with the engine of a Cinquecento. Like it? Ok, but real IT should be done with real tools
thank you techblog for giving me wonderful information