Hacker News Reader

Comment by mindcrime | Hacker News Reader

realise that ORMs are inherently stupid.

That's quite the claim... Care to expand on why you think ORMs are "inherently stupid"?

Because you can't cleanly map objects to sets nor sets to objects. Sure, if you want to pretend an RDBMS is an object store you certainly can, but you'll be forced to have an incredibly stupid schema, and will miss out on much of the benefits of a good RDBMS.

Turning a powerful SQL database engine into an object storage emulator is just sad.

If your underlying data suits objects better than sets, consider using something that's designed for the job, like one of the many non-SQL database systems.

  Although it may seem trite to say it, Object/Relational Mapping
  is the Vietnam of Computer Science. It represents a quagmire which
  starts well, gets more complicated as time passes, and before long
  entraps its users in a commitment that has no clear demarcation
  point, no clear win conditions, and no clear exit strategy.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...

Well worth reading.

Also:

http://database-programmer.blogspot.com.au/2010/12/historica...

http://www.codinghorror.com/blog/2006/06/object-relational-m...

Unfortunately I didn't have time to read these articles in depth, nor do I have the time to write a detailed answer now - sorry. But it seems to me that the situation has changed since these articles were written, at least concerning the tools I know best (which are .NET and C#).

We now have built-in support for data (sets) manipulation in C# and Entity Framework makes things like db.Customers.First().FirstName with syntax support totally real. Many of the premises these essays seem to be based on (like "the languages in play lack any real specialized data structures") are just not true anymore.

Also, I would like to know more about why using an ORM like EF would force me to "have an incredibly stupid schema".

Turning a powerful SQL database engine into an object storage emulator is just sad.

Now that I can agree with, but I would consider that to be a (subtly, perhaps) different position than:

"ORMs are inherently stupid".

IF you have the option of choosing a native object store for persisting objects, then - by all means - choose it. But in cases where an RDBMS is the data store of choice for whatever reason, and you still have to store your objects there one way or another, I'd prefer using an ORM like Hibernate over hand-rolling all the low-level SQL/JDBC code to marshall objects back and forth between the DB.

I think ORMs are "inherently stupid" (or: "quite likely to be leaky as abstractions") because they don't necessarily share a theory with the underlying databases ("something like but not exactly relational algebra") and I don't think many people spend time proving that the OO-like theories can be properly embedded into something-like-relational-algebra.

Not saying you can't get work done with them, but it does mean that they're likely to leak.

also without an ORM do you just hand roll all your object graphs? I'm picturing a sea of builders and factories which amount to a hand rolled ORM anyway. Or are you practicing stringly typed programming? Ultimately in any strongly typed language you're either going to make/use some kind of mapper or else abandon typing and use maps/dicts which raises the question of why you're using a strongly typed language in the first place.

First, you can have strongly typed languages that aren't object oriented. Instead of using maps/dics, you could use records.

The thing I don't like about ORMs as they are typically handled is that you map objects to tables up front, and those are the things you can query for.

Using something like Linq, you can more easily treat your database as relational, and still return strongly typed objects. These objects can be the thing you wanted to return from the query, which is not necessarily mapped directly to the entities in the database.

I like this approach more, since you still get one of the main advantages of a relational database: you can get the data in the shape you want, not in the shape it's stored.

Could you explain this a bit more in depth if you have a chance? This is extremely interesting, but I'm not familiar with terminology associated with strongly typed languages. What do you mean by using records instead of maps?

You can think of a record like a C struct. It's key value pairs, but the keys and their types are chosen at compile time. There are no methods or anything on them, they are just data.

An example from OCaml:

type person = { first_name: string; last_name: string; age: int }

In a language that has some form of anonymous records (like C#'s anonymous object) and structural typing, this would let you work with relations in your language, much in the way you'd use them in SQL.

I personally like treating data as data. It should be immutable, and therefore there is no state to hide, which means there isn't much value in your types being objects.

It also allows for nice things like pattern matching to work with your data.

You still need some kind of mapper though to go from the SQL results to your record type, even if it's using convention such as the records fields are named the same as the table columns you're pulling from. I'm not arguing that for instance Hibernate is awesome, just that you need something to fill that gap, and you can do a lot worse than Hibernate, particularly within the limitation imposed by Java. Personally I prefer something like this ( http://hackage.haskell.org/package/esqueleto-1.3.4.2/docs/Da... ), but will usually settle for Hibernate or similar in less powerful languages like Java.

> you can get the data in the shape you want, not in the shape it's stored.

If you build a database view, you can often trick an ORM into thinking its a table.

most ORMs have a query language too, it's not just "Linq". Orms are good for development purposes and you can always do raw SQL queries within ORMs at some point.

The thing that's nice about Linq is the integration. You can directly reference variables in the things you're querying, and then either fill in an instance of an existing class, or generate an anonymous object.

For example:

  var query = from c in customers
              join o in orders on c.ID equals o.ID
              select new {
                c.Name,
                o.Product,
                Address = c.MailingAddress
              };

Of course, anonymous objects in C# can be a pain in the ass, since you can't usefully return them from a method. Something like Scala's structural types would solve that problem.

I don't really like C# that much as a language, but I do like the Linq approach.

Reply on news.ycombinator.com