Here’s a thing that’s come up already. ORMs, or Object Relational Mapper, are a RDBMS based thing for devs that want, in essence a statically typed object to deal with when writing code (yes, I know there’s a ton of other things an ORM can do or be used for, but I’m going with a simple explanation here, here’s more info). For some situations, I can see where that’s a productivity booster, but in other situations it is a very broken ideal. Especially when it comes to needs around highly complex query needs, performance and a host of other functionalities when you get into the higher end demands of Enterprise or *web scale* type systems.
Two things that has brought up this question in a new light, is:
- One: Why would you use an ORM in a dynamic language like JavaScript, that has a simple native format like JSON? It tends to make far less sense to do this. What’s your take? Like the idea? Hate the idea?
- Two: In a schemaless database, forcing an ORM on something that is built specifically to not have this featureset (for a number of reasons) seems to break the design ideas of the systems. Whether it is Mongo, Riak, Cassandra or whatever, why would you actually want to or not want to use an ORM? I’ve got my own thoughts but would like to know what people think about this notion.
-Please comment, I’ll be diving into any feedback too.
ORMs are a useful abstraction when you need them. With document databases they are a bit of a waste of effort. But in the relational world, the bigger the project the more useful ORMs are.
I think most of the time people still uses ORMs because is what they know, they’ve been doing it for years, and mayor players such as NHibernate or EF are pretty mature products nowadays (so, no surprises in production here).
The other big “why” I can see, it is because RDBMs. This is the kind of storage solution that almost every customer want to use (at least on every project I’ve worked on)
But I think we are facing a paradigm shift, where NoSQL databases are going to go mainstream and the impedance between objects and tables will desappear. I think, though, people will still be using ORMs for a long time to move records from a NoSQL storage to a reporting relational databases or stuff like that.
So far, the only NoSQL database I’ve tryed is RavenDB, I found it easy to use and way more productive than the relational counterparts, but I never tryed in commercial apps yet so no strong opinion….
Answering your question, I think ORMs suck big time, but they are proven solutions and they are going to be around for a while.
Our lead architect wrote a custom OODBMS for our NoSQL product. We experienced a real boost in developer productivity (sometimes 35 developers). Admittedly this was on Btrieve for an novel ERP app. Really how many Mongo, Riak, Cassandra databases are truly no schema… why not boost productivity?
I can see doing that, but it also reduces the effectiveness of the root use of some of the databases. However, if usage is low and the primary concern is to get a database that doesn’t require changing the database much, it would I suppose make sense to roll all the changes through something like an OODBMS for productivity and then just have that manage any actual change to the underlying database – regardless of type. I’ve seen this before and in many ways, that’s what the ORM code first type changes in RDBMSes are for.
What was the OODBMS that was built over the NoSQL db you guys had? Was it open sourced? I’m curious. 🙂
We changed the database ad hoc and often. Chris Hanson and Ken Seahart wrote our OODBMS from scratch, key is new developers don’t need to fish around for data (the schema was a document itself). I wanted to open source (I would now) alas execs shot me down.
I started out using ORM on one of my projects where I had to provide sustained traffic of more than 100k queries per hour with usage spiking at about 350k queries per hour. EF started out performing very well, outperforming even SPs in the beginning. But over a period of few hours EF started dragging its feet (application along with it).
SPs didnt provide as much performance but it provided consistency in terms of performance. My product is a long running one, it can run for months before it gets recycled. Since then no more ORM, I need to have consistency and performance both.
However I have found that ORM is very helpful when working on small projects where I need something static to code against.
Big no no for a big scale project but may be good fit for small one.
1) I wouldn’t. JSON is lightweight and easy to transfer over the wire. It can be serialized/deserialized easily on both client and server side. I may use oojs client side, but the ORM lives on the server and applies the business logic on it’s way to persisting data to the db. Even if JS models had save (or even populate) methods, they’d still serialize to JSON and send to/receive from server via Ajax.
2) ORMs are for abstracting db’s that devs don’t want to bother to learn to use correctly. Nosql databases achieve this objective implicitly. There seems to be no gain here, just busy work.
ORM’s are simply an excuse for programmers who build applications that *already* have too many layers of abstraction to add one additional layer of abstraction (and thus eventually building the ultimate “extensible” one-application to rule them all).
If your application is data-driven using data that is *related* to each other in a meaningful way, suck it up, pick a RDBMS, learn SQL, and leverage the custom settings of the RDBMS fully. The idea of “database independent” applications is bullcrap – in the enterprise world, the data’s going to be around a lot longer than any specific front-end.