Too Cool for Internet Explorer

Saturday, January 5, 2008

Ruby and Active Record vs SQL


There was something bugging me these last days...

I have seen all kind of facilities: act like this, act like that, and a lot of “Rails makes it for you” all around. But, when your application grows, or much more common, you have to deal with legacy applications and data models, things don’t work so easy.

Two weeks ago when I was testing some Ruby / Active Record code accessing oracle tables on my legacy enterprise model. Everything was fine when I was testing some simple table access.
Then, I remember my current java work. Dealing with much more complex tables and queries. In fact, queries are the starting point on my java applications. We have tables with more then 50 columns, an unnormalized table to avoid several joins, three unions on a single query to catch “old database model” data, things like that!

And on an “enterprise” environment, there are rules to be followed.
For example:

  • Never EVER use “select *”.
  • Every single query MUST be “explained” and DBA approved BEFORE going into production state.


So, Wonderland far way, I start researching some practical alternatives, and find these:

Lesson learned: automation is fine, abstraction is a must, but real world is Rock solid, don't try to kick it out.

Some times will be necessary to SQL your code.

1 comment:

Anonymous said...

You're right about that. For my first rails application, I had to wrestle with a (poor) legacy schema.

My code is full of sql code - ugly, but necessary. Also, the lack of stored procedures really hurts.

That said, rails has its advantages ...