Mechanical

Moving Object-Relational Mapping to the Database

For anyone who has ever used Object-Relational mapping, you know that it's usually something done in fancy code libraries. You also know that such mappers are often slow and buggy. Next Wednesday, Portland Perl Mongers will be presenting a talk on Moving Object-Relational mapping into the database. This talk assumes you know databases, but even though the examples are in Perl, it's not really about Perl so you don't need to know the language.

However, if you've ever stumbled on the Object-Relational impedance mismatch, this talk will show you a powerful technique for minimizing this problem. Further, you start leveraging the true power of databases and gain a performance boost both for the application in terms of speed and the developer in terms of development time.

MySQL users are excused as it turns out that this "database" is still too primitive to support the techniques discussed (though it's finally getting there).
  • Current Mood: working working
My initial reaction is, "Sweet Jesus, no!!!". I wouldn't mind seeing a counterpoint, though. I hope he posts his slides to at least make me think about it more.

Oracle supports objects on the database side, though I don't know of a single person who uses them.
Ah, thanks for the link. In fact, this isn't what I thought it was about. Before I saw the slides I thought he was talking about actual objects on the DB side, which you would then map to a class on the language side.

After reading the slides, I'm ambivalent. Triggers are such a double edged sword. Yes, they can make your life simpler. They can also be a pain in the ass when it comes to debugging.

There's a definite for/against crowd out there when it comes to triggers (and stored procedures). For an opposing view, take a look at http://www.loudthinking.com/arc/000516.html.

I'm sure there are many others out there.

(Reposted as the first post was missing a paragraph at the end)

I'm certainly ambivalent on the subject of triggers and stored procedures. However, I realized that most of my ambivalence dealt with the fact that they have side effects (or are side-effects) and are often "behind the scenes" and invisible. Things like that are awful.

If, however, they are designed and applied in a cohesive fashion, they can be quite useful. Regrettably, I first developed a prejudice against them when working with SQL Server. It made them quite invisible and sometimes I spent hours debugging problems which shouldn't have been there. However, this doesn't mean they're always bad (just like it doesn't mean that goto is always bad). In the case of how David decided to store objects in the database, the overall design is aimed at one overarching idea: managing object data in a more natural fashion.

As for your link, I rather thought the gentleman stated his position but didn't back it up. On the other hand, he linked to a blog entry supporting his position and I was rather disappointed. The latter author is missing the point. Sometimes business logic belongs in the database. Sometimes business logic does not belong in the database. Coming up with this "never, never, never" idea generally shows an inability to think rationally about a subject.

If I have a single application accessing my database, maybe it's better to bubble up the business logic to the application layer where I can explore the domain better and respond to requests faster. If I have more than one application writing to the database, you bet I don't want someone violating a unique constraint or a foreign key constraint.

The latter author does address this point, though:

As for the ongoing ‘the sky is falling’ discussion about what if some other device accesses the RDBMS, it’s the same dilemma as ‘what if some other person accesses our document, and starts changing it?’ There are ways to manage that. Yes, we’re always exposed, always vulnerable to all kinds of attacks, but that’s how life is. You should start getting used to it by now.

What does he say to support this assertion? Nothing. Personally, if I'm writing an application for a client, I think it's unethical to not provide them with the best data integrity that I can. If a constraint says that a person's age should never be less than zero, there's no reason a buggy application should be able to circumvent that.

Yes, for the record, I think DHH and Alex go way too far. I'm pretty sure DHH has come to his conclusion as a result of his life-experience, i.e. only having used MySQL (afaik), where constraints aren't enforced and some of the features he denigrates were simply never available to him. Thus, the MySQL way became the One True Way of doing things.

His comments about "integration databases" show a certain lack of experience. All databases are integration databases, by his definition, because sooner or later, someone is going to access your data from another application.

Really, I guess that article didn't have much to do with triggers and stored procedures per se which, btw, I *do* use. I guess I'm just at a point right now where I'm trying to figure out, in my own mind, where that fine line is between app logic and db logic.

Ok, enough rambling. :)
Is this the same one that was at OSCON or is it going to contain new yumminess?
Went to the OSCON presentation. I'm trying to remember if he was one of the ones who had too much to say for the period of time given. Might be worth going just to hear the different Q&A. Audiences make every lecture a unique experience.

Thanks (:
Same presentation, though I'll probably add some stuff about data domains and aggregates. It took about 40 minutes at OSCON and I gave it to the DC Perl Mongers last month in just over 30. It's too short, if anything. I'd like to get it up to an hour.

—Theory
So, the postgresql slides say for INSERTs on a VIEW

  CREATE RULE insert_classical AS 
  ON INSERT TO classical DO INSTEAD ( 
    INSERT INTO album (title, artist, publisher, isbn) 
    VALUES (NEW.title, NEW.artist, NEW.publisher, NEW.isbn); 
    INSERT INTO album_classical 
           (id, composer, conductor, orchestra) 
    VALUES (CURRVAL('seq_album_id_seq'), NEW.composer, 
            NEW.conductor, NEW.orchestra); 
  ); 


Does this run the risk of a race condition on seq_album_id_seq?
So er, are you going to tape this or something? Maybe just bring an iPod with a microphone?
Didn't think about that. David (my boss) is the one giving the talk). I'll ask him if he's going to tapee it.

I might add that the slides cover everything. The only thing which might be missing is seeing David run the "let's see if this works" examples but you still get to see the output on the slides.
Perl
Actually, the examples are in SQLite and PostgreSQL. SQL There is no Perl code per se, just a few examples that use $vars to make clear what's a variable and what's not.

—Theory