An article by Geoff Wozniak titled What ORM’s have taught me: just learn SQL was doing the rounds of Hacker News today and raises some interesting points. Similarly, I have the same feelings towards libraries like jQuery abstracting Javascript to the point where people know the library not the language.
However, I think the advantage of ORM’s far outweigh the disadvantages. I do agree that ORM’s aren’t some cure-all silver bullet that should be used for everything, but there are too many things that ORM’s handle for us like handling basic CRUD operations and handling complex relationships (within reason) which save us time and money.
We as developers are increasingly taking on more responsibility, having to abide by strict deadlines determined by clients and people higher up in the business, often with little room for pushback.
Sometimes we need to move fast and when it comes to interacting with a database, there is no denying an ORM can sometimes be the fine line between finishing on time and losing weekends getting it done.
Sadly, at the end of the day a client or business only wants to see results. Usually they’re impartial to how you achieve them, even if it means creating technical debt further on down the road. This is how most of the industry operates and will continue to operate for sometime.
Unified API for interacting with databases
Modern ORM’s like Rails’ ActiveRecord turn your database tables into objects which allow you to work with them like so:
post = Post.new
post.title = "Blog Post"
post.text = "This is my blog post"
post.save()
For those of you who know how to write raw SQL queries, you will know that the raw SQL variant of the above query is anything but pretty. While not an overly complicated example of a query, you can clearly see what is being inserted and where.
If you are working with a database that adheres to a normalised structure, then an ORM is the perfect accompanying component for your database. Using an ORM with a denormalised database structure while not impossible, can sometimes lead to a bit of pain. Most ORM’s assume your database is mostly adhering to a normalised structure.
This means regardless of whatever database you use, provided the ORM has a driver for it, you interact with it using the same logic you would any other database via the ORM. This means any developer regardless of what databases they do and don’t know can write database logic.
In this day and age where web applications are becoming more complicated and we are no longer just using one database in our applications, an ORM can break down the barriers of communication between different databases using the one unified syntax thus keeping things fluid.
Less Code, Better Quality
There is no doubt that ORM’s require less code to handle even the most complex of database queries (especially in instances where multiple tables are being joined). One of the biggest advantages is less room for error. Because the good ORM’s handle escaping your data, data validation and query generation, you know you’re not going to be caught up in a complex SQL query on a missing single quote or misspelled field/table name.
Once again, most ORM’s come with in-built security features your standard SQL query doesn’t have out of the box. A raw SQL query written by the hands of an inexperienced developer could be a costly mistake, an SQL query using an ORM written by an inexperienced developer has the advantage of utilising whatever enabled security features the ORM has turned on when queries are executed.
Query Generation
One feature that don’t realise most ORM’s support is query generation. While ORM’s are great for development, they all mostly support generating raw SQL statements if you want to only use an ORM for development purposes.
I personally use ORM’s in production and development because there is no point in calling raw SQL queries. Writing your own queries and executing them from within your application is essentially writing a poor mans ORM anyway.
Those who oppose the use of ORM’s also need to understand they don’t have to adhere to any kind of structure the ORM proposes. You can write raw SQL queries if there are things you want to handle yourself without even using the ORM, you can mix both standard SQL and the ORM functionality together.
Relationship Management
Nobody likes writing SQL JOIN queries, especially when you need to join 4 tables together. If I had the chance to only list one advantage of an ORM, relationship management would have to be it.
Being able to join multiple tables together and clearly see in my logic what is happening is invaluable. As many people are well aware of, SQL is a mess when you start doing anything overly useful with it and can be hard to read. An ORM gives us the option of clearly separating our code and querying our database.
Sure, you run the risk of potentially allowing the ORM to write a slow query, but there is a strong possibility the team behind well-known ORM’s like Nhibernate, Doctrine, ActiveRecord and so on know a little bit more about how to write an efficient SQL query than you do (unless of course, your day-to-day job is working solely with databases).
Accommodating Schema Changes
If your database schema changes, it is a relatively simple task to go through and adjust your models accordingly. Provided you’re using an MVC structure in your application and your database logic is within a model, you only have to make a change once.
This means things are kept cleaner and you are spending less time changing all occurrences of a renamed table field or modifying a complex JOIN query to accommodate for a newly added field.
Here it comes another ORM fanboy. I don’t agree with most of your blanket statements. Simple CRUD stuffs are already simple enough in SQL and complex queries are simpler in SQL as well. ORM is just a failed experiment.