EVE Technology Lab

/me shudders at the mention of an ORM.

From a DBAs perspecitive, ORMs are pretty much the devil. They divorce people from the technology they're actually using, so the ORM ends up writing really bad sql to use the underlying tables.

And they don't think about the indexes they need to create, because the ORM hides it all.

Sure, it makes things faster development wise, which saves money. but I don't have to like them.


Anyway, in this instance, I guess it all depends on what you're going to do with the data. I /suspect/ you're going to be writing reports with it, rather than manipulating it. Which suggests, to me, using regular SQL.

I think the point of ORM, at least Entity Framework, is to have you do as little joins as possible, but just look up everything when you need it. At least, as long as you use deferred instead of eager loading (which would probably load half the DB with the SDD)

Using an ORM is all about having an abstraction layer hidding your persistence layer. It will help you migrate from one solution to another, just by modifying couple of configuration files. NHibernate, for instance, can handle a wide range of solutions.

ORMs provide change tracking capabilities, transactions etc... all the kind of stuff you will have to implement yourself and maintain !

As for the DBA perspective, you will have to test the generated scripts and create indexes where it matters. Also use views and map flat objects to them if reading performance is important to you.

S.O.L.I.D !

Anyone posting in absolutes about ORMs is showing real ignorance. It largely depends on usage case, and the ORM in question.

There are lots of different approaches and implementations, and not all are created equally. Most ORMs also give you a way to drop to raw SQL if you just can't make it work for certain queries. Depending on what you're doing, an ORM can save you a lot of time, help protect you against injection attacks, and make your code a lot more readable. Of course, they can also lead to SQL-soup behind the scenes, but that's something you have to keep an eye on.

Since I assume we're talking about a hobby project here, the main things are probably productivity, and "fun". So do what is more fun, because historically, you're going to run your project for at most, a few years, burn out, then close shop. The further you can get before losing steam, the fonder you'll look back on your effort :)

I'm a programmer not a DBA, so my main interest is saving on typing and reducing boilerplate code. ORM is one way of achieving this, but it can be a bit of pain to set up. Also, quite normalized databases like the SDD will usually need another transforming layer to put your data into more useable domain classes.

I also use plain SQL through Spring's DAO and JDBCTemplate which is fab for not needing having to worry about irritating exception handling code. It's a bit less reusable than the JPA classes, but it's so easy to sling together another query I'm not bothered.

So I'm using both, whichever suits me at the time.

For you DBAs, ORMs aren't necessarily more evil than writing SQL. Just like hand-writing SQL, you still need to tailor and tune it, just in a different way.