Comment by jbarciauskas | Hacker News Reader

Comment by jbarciauskas | Hacker News Reader

This article reiterates a fundamental point that object stores quite clearly present less friction during development than relational stores. This is plainly true: your domain object is meant to model the domain, and if you can store it directly that is the best you can hope for. There's a reason there's a whole topic of study and research called "Object-relational impedence mismatch" (http://en.wikipedia.org/wiki/Object-relational_impedance_mis...)

However I think ORMs are too quickly dismissed. In the simplest case, an ORM can appear to be a key-value store at the API level. Of course that is a gross abuse of a relational store, but there's no reason it can't be done. Additionally, the author fails to note that an intelligent ORM can provide a caching layer that improves performance over raw SQL. A more detailed examination of the various patterns to resolve the impedence mismatch, such as active record versus data mapper, ORM caching strategies, and how those compare to a key-value store solution, I think would be a valuable topic of discussion.

If you find that your objects don't map to a relational structure, it's probably because you're doing things in the wrong order.

The early design for any system should be done in your database's diagramming tool. Figure out a data structure that holds the information you're application is going to use, and once you've got that you've also got your object model.

You can then generate your whole backend by pointing your favorite code generator at the database schema. You'll end up with the same User, Customer, BlogEntry or whatever objects you would have come up with if you'd just started coding from scratch, but they'll come with a .Save() method that stores them away in a data model that fits them perfectly.

This sounds like the waterfall model of software development to me.

I mean, don't get me wrong, this is what I do, too (I only started using MongoDB over the weekend after years of MySQL and Postgres), but the similarity to the arguments is pretty interesting.

I suppose, provide you never changed the data model once you'd designed it, and you designed the entire application in one go, before writing any code. That would sort of negate the advantage of having a datalayer that regenerated itself on the fly every time you messed with the schema though.

Personally, I find that starting from the schema makes one more agile (small 'a'), not less so.

How do you deal with modifications to the generated code when it's time to change the schema?

I guess the answer is to just make your domain objects glorified structs. I've never liked that answer, as it seems to defeat the whole point of object oriented design.

If the ORM layer is providing a caching layer on top of the RDBMS, that caching layer is effectively a non-relational store for the data. If that works better, why not use it as the primary store?

Not necessarily - you could store a resultset based on the query and parameters, and if the same query and parameters come within a certain amount of time, you return the whole resultset from the cache. In this scenario, the resultset could contain a filtered list, aggregate functions, etc, that are more difficult to replicate in a key-value store.

That is exactly what Oracle Coherence (nee Tangosol) does.

Persistence?

Because you want to do arbitrary queries on the data? Because the data needs to be exposed to other applications?

As you state in your article, the ability to easily phrase ad-hoc questions and have them answered with almost no programming is a very useful tool.

Why not use two tools where two are needed?

Many databases run a mix of OLTP (which requires fast cache and no ad-hoc queries) and ad-hoc business intelligence queries.

> easily phrase ad-hoc questions and have them answered with almost no programming

Queries are programming, the worst kind, programming without composable abstractions.

What people actually mean when they say this is they like having a workspace and a live environment. It's like working in Smalltalk or Lisp in a live image.

Put your email in your profile, I'm disappointed you didn't continue the discussion yesterday after saying do it over email, which you don't make available.

Look, honestly sometimes ORMs are very helpful for developers, especially when they're built directly into a framework (e.g., Django). They may be more useful if the database itself had knowledge of what you're trying to do (hint, hint). If you're arguing that they will have necessarily worse performance characteristics, you're wrong.

Source: I'm currently a SDE intern in the SQL Server team at Microsoft.

It's not plainly true at all. You write as if there's a rigorous, agreed-upon notion of "object". Not so. As such, it can be as vague as you need it to be.

Not every person agrees on every aspect of the relational model, or of the SQL implementations.

There is a rigorous notion of .net object.

Relational algebra is agreed upon. SQL is loosely based on it. On the other hand, there's not even a single agreed upon notion for objects.

There's a rigorous notion of a .NET object but it's not compatible with Java's, C++'s, Smalltalk's, ...

Reply on news.ycombinator.com