I read this post last night, and I noticed it was from 2006. I could go either way on the ORM, database thing, but I was just wondering if everything bad Jeff said about ORM still applies even now considering the post is from 2006.
+1
A:
I think it does.
I think the last sentence is the most interesting of all: "I tend to err on the side of the database-as-model camp, because I think objects are overrated." Java, C++, and C# are certainly the dominant languages, but functional programming is making a comeback with F#, Scala, etc.
duffymo
2008-12-31 21:42:34
Comeback - they've never been a dominant model before, so 'breakthrough' might be correct :D
Jonathan Leffler
2008-12-31 23:45:07
+1
A:
This isn't my area of expertise, but I worked in Rails for about a year and I think ActiveRecord solved most of the DB Mapping problem. I realize it has a few issues, but I think it did a fantastic job.
I don't think his post took into account the possibility of the framework itself (in this case AcitveRecord/Rails) defining the database AND the Object Model, which--as far as I can tell--makes the problem go away.
Since this is the opposite of the first two responses (basically that the post is outdated) I feel like I'm probably not understanding something; If that's the case please correct me instead of just voting me down because I think there is an important point I'm missing.
Bill K
2008-12-31 22:10:00
It doesn't make the problem go away, it gives the illusion the problem is solved but creating horrible performance and design limitations compared to using the full features of a database and SQL.Pure object databases (which is essentially what you are talking about) never caught on.
Kendall Helmstetter Gelner
2008-12-31 22:34:22
++ Kendal. The design of ActiveRecord naturally leads to terrible performance bottlenecks (the downside of wonderfully easy-to-use abstraction layers).
Tom
2008-12-31 23:25:57
ActiveRecord (the pattern, not the Rails implementation) is fine if you use it in the circumstances for which it's designed. But there are a bunch of other data access patterns in Martin Fowler's PoEAA book, which seem to be ignored by Rails!
Bill Karwin
2009-01-01 01:36:30
Bill K
2009-01-02 17:42:14
Yeah, hold on... I doubt active record is the problem so much as Rails. Ruby itself is known to be slow (1.9 helps a lot) and Rails is also slow.
Matt Olenik
2009-04-17 09:44:42
Bill K
2010-03-01 19:21:20
+11
A:
It's still true.
Even more than OO software, the database suffers if it isn't treated precisely the way intended. And it wasn't intended that you should interpose some abstraction layer in front of it.
I think of impermeable abstraction layers as trying to build a Lego castle with all the pieces closed up into a pillowcase. SQL is damn hard to do correctly. It doesn't share many patterns with procedural programming, and best practices for one can be the opposite for the other. You need to be able to grok every single item in a SQL statement, and have a pretty good idea what it's intended to do, and what it in fact does.
Lots of people seem to think that, like horseshoes, close is good enough - if the right answer pops out, that implies you're nearly there. In SQL, that's simply not true.
RoR and the ActiveRecord pattern have deservedly earned a reputation as dbms resource hogs for this reason. Optimized ActiveRecord design is more often than not suboptimal SQL design, because it encourages SQL statement decomposition.
le dorfier
2008-12-31 22:16:07
actually, SQL is dead easy to do.. if you know what you're doing. That can be said about every other technology though, so if you think its hard, you should not try to force it using an ORM, you just need to make friends with a DBA (who'll think procedural coding is impossibly hard :) )
gbjbaanb
2008-12-31 22:40:57
"SQL is damn hard to do correctly. It doesn't share many patterns with procedural programming": erm, isn't that the point of ORM? i.e. for procedural programmers who, for whatever reason, want to avoid getting involved with SQL? I'd hope the tradeoffs are known and deemed to be acceptable.
onedaywhen
2009-01-02 09:46:46
I know SQL, and yeah I don't really think it's that hard...(although it was hard to learn...once you've got it, it isn't that bad)
leeand00
2009-01-02 14:56:53
One of the most popular (.NET) ORMs suffers from SELECT N+1 straight out of the box
Chris S
2009-04-17 09:46:04
+4
A:
I can only speak for my experience. I use DAL and DTO's, and I am still capable of performing pretty complex queries (joins and all), and also I am able to resort to SP's or custom SQL whenever I need. It made my life easier, my code consistent and my deadlines more attainable.
Otávio Décio
2008-12-31 22:24:34
Just because you can do it, doesn't mean you should. You've ended up learning a whole nother paradigm, adding to the complexity, without replacing the other two.
le dorfier
2008-12-31 22:28:01
@le dorfier: My 8+ years of many successful projects using this approach is really the only validation I need, I was just trying to offer a different perspective. I don't believe I added complexity, but reasonable people can disagree.
Otávio Décio
2008-12-31 22:32:00
Yes, and I think RoR is a useful framework. I wish it could have the isam it was designed for, instead of being mismatched with RDBMSs. Then you *could* use it for optimized persistence, for a net complexity gain. (Sometimes complexity is worth it; but it doesn't help to pretend it's not there.)
le dorfier
2008-12-31 22:39:07
I wouldn't use RoR, or even Hibernate, they simply don't scale. Believe me, I painstakingly profiled, made it thread safe, and I can run heavy processes with it - without manually writing a single line of SQL.
Otávio Décio
2008-12-31 22:39:32
I wouldn't try to imply that it can't be done - it obviously has been done. But painstakingly profiling a database is IMHO best done in the database; and thread-safety simply doesn't come up. BTW, I upvoted you. Your model is much more viable than ORMs, IMHO.
le dorfier
2008-12-31 22:56:30
@le dorfier: yes, by profiling I meant really looking the time it took to run the generated queries in the database itself, studying the execution plans, using parameters, etc. The multithreaded part is to allow many threads on client code to connect and run without interfering with each other.
Otávio Décio
2008-12-31 23:06:24
+5
A:
Yes.
Object-oriented is still object-oriented and Relational is still Set-oriented. Nothing has changed in these two paradigms in the past two years to make them work better together.
In many people's eyes, SQL is ugly, complex, and confusing. But trying to make an object-oriented interface to perform the same functionality is always uglier, more complex, and has a steeper learning curve.
In all programming, there is a tradeoff between flexibility and assumptions. Frameworks (such as Rails) try to solve the problem by being "opinionated." That is, they limit flexibility of either the relational or the object-oriented aspects of the problem, making assumptions about how data is structured, and what operations you can do with it. Naturally, simplifying the problem space makes the solution simpler as well.
In addition, it's frustrating to discover that an ORM framework is incomplete, so some ordinary operations in SQL have no solution in a given ORM. This is also a consequence of "opinionated" frameworks.
Bill Karwin
2008-12-31 22:38:35
"Naturally, simplifying the problem space makes the solution simpler as well."- Bill KarwinGee Bill, thanks, I take comfort in that statement. :)
leeand00
2009-01-02 14:58:53
But wait a minute, doesn't a framework like Hibernate, support a record-set type thing (i.e. Projection Queries?) And probably the reply I'm going to get at this point is, what's the point of using a framework when you have a projection-query that operates just like SQL considering the overhead.
leeand00
2009-01-02 15:00:33
According to ohloh.net, Hibernate consists of over 800,000 lines of Java and XML code (not counting comments, or other Hibernate-related tools). Is this overhead really necessary, considering it's just as hard to use as SQL and doesn't really solve the problem any better?
Bill Karwin
2009-01-02 19:27:30
+2
A:
I think starting from the assumption that Jeff's conclusions are correct is not necessarily good; having maintained stored procedure code as well as JDBC-based data layers, I can say that these caused maintenance problems galore, mostly related to the inability to understand what was going on at a higher level.
A database is necessarily low-level; it stores numbers and strings essentially. Business logic is high-level. This is why we have abstraction.
Personally, I think the Rails/ActiveRecord way is the best solution to having an object/domain model but also being able to take advantage of a relational database.
So: don't throw out ORM, but don't default to it either. It's a tool that solves certain problems. To ignore it would be ignorant and to always use it would be arrogant.
davetron5000
2008-12-31 22:40:08
+1
A:
A lot of web 2.0 companies are working on key-value stores. And all these companies have to go through the same painfull process of making it work.
If ORM is the "vietnam of computer science" then building your own key-value store is probably the "Iraq of computer science" :-)