The second rejected paper: the ORIM again

Object-relational impedance mismatch is by far my favorite research topic, mostly due to the fact that it has a very practical implementation. I would make even stronger statement: the most rewarding optimization is the one when you can reduce the number of SQL statements executed when a web page is rendered and all of a sudden it is loaded 50 times faster (and I mean actually 50 times, not figuratively speaking!).  It always looks like a magic – and I haven’d done anything!

This been said, the ORMs are my worst enemies, and I am always looking for opportunities to promote the better ways of communication between a database and an applications. Most of the time the human factor appears to be more important than the technological challenges, so I always think about these projects as battles.

At Braviant however, first time in my professional career I had nobody to fight about this issue – the app developers were completely on board with my approach since day one. Which allowed us to develop something really cool, and to optimize the interaction between databases and application to the point of absolute perfection. SO, when my husband suggested we’d write a short paper about this project, I had no doubt it will be accepted – because two of my previous papers on the same subject were accepted to the very serious conferences.

Life proved me wrong :), I am not going to name the conference and the workshop, but I have to make some comments about the reviews, so that the level of my frustration can be understood.

One of the reviewers asked: why we think that the number of round trips defines the response time of the web application. Another reviewer asked, whether we tried to use Mongo DB :))). And why we think that (de) serialization of the JSON takes negligible time. And why we think Hibernate is worse.

I think the only valid objection was, that the topic of the paper is not relevant to the workshop topic.  And the latter might explain the whole story.

Several years ago, when I started to attend the database conferences again, after fifteen years of absence, I made an observation that a significant number of the attendees never saw the real applications, and never had deal with performance problems, Fortunately, I’ve also met and got to know some really outstanding researches, whom I admire and feel honored to be aquatinted with, so… I am sure I will find the right place to showcase our work.

And may be it’s time to get back to my old “HDAT” workshop idea,,,

And for my fellow Chicagoans: I will be presenting this work this Tuesday, Feb 13 at the Chicago PUG meetup!


Filed under research

8 responses to “The second rejected paper: the ORIM again

  1. Correct me if i’m wrong, but it seems to me that IF the page is designed correctly, it SHOULD have no more than one SQL request. If one has SQL requests for menues/headers/whatever NOT touching the main contents, those requests SHOULD be cacheable and be (on average) cached somewhere (memcached is fast!). If one needs more than one SQL request per content – it means that the page will not fit in the brain of the reader, or on the screen of his phone, and most probably it has to be separated on two (or more) pages.

    • Henrietta Dombrovskaya

      You are 100% correct, but the problem is, that this not how any ORM would work. An ORM would map each table to a separate class, and although in many cases you are allowed to pre-program joins, there are high chances that if you need to display a person will all accounts, addresses and phones, you will end up with a dozen of separate SQL statements.

      • Why not map such “not-very-usual-and-unobvious” code to some separate method, just deeper in class hierarchy? It’s just because of somewhat lazy application-level developers, struggling to learn SQL, or organisational separation of the control over the code?

        • Henrietta Dombrovskaya

          All of the above and more. There is a significant variety of these “other” cases, and often a different SQL should be used for different combinations of the search criteria (for example, when the Sales Reps search for th customer by “any” set of conditions). At the end it means walking away from an ORM. Actually, my talk in Moscow which you heard, was just about that. It’s a very controversial topic.

  2. May be it would be more influential/usefull for community to write something popular on the subject to some general public blog – reddit, for example? Or in russian on habrahabr?

  3. Henrietta Dombrovskaya

    This topic is widely covered since 1980s :))

    • Well, it doesn’t mean that young developers, who have just learned some ORM, so they are able to write working prototypes, have read all (or at least some of) the articles on the topic since 1980’th.
      May be it’s better to write something like “feature matrix” for some poplar ORM’s. E.g. with columns as typical situations (like ‘get all objects fitting criteria’, ‘get with join from another table’, ‘update multiple objects in one shot’, ‘insert multiple objects in one shot’), rows with ORM, and flippable cells – red side for “bad and stupid” solution and green for “fast and clever”.
      Or, may be, such a cheat sheet already exists?

      • Henrietta Dombrovskaya

        It’s actully not that easy to write a “generic matrix” for ANY case, not a particular app, but I’ve already planned to write a separate post about it – coming soon!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s