Comments on: Railers Need To Stop Not Caring About The Database

By: Aladdin With A Lamp » 『Ruby on Rails』|很好很好的资料！

Aladdin With A Lamp » 『Ruby on Rails』|很好很好的资料！ — Thu, 12 Feb 2009 12:56:51 +0000

[...] Railers Need To Stop Not Caring About The Database [...]

By: Texor

Texor — Tue, 07 Oct 2008 18:44:47 +0000

He, he,… I’ve been on IT business for 17 years, and must admit that Rails make me nervous when I think about performance in general – and DB in particular. But, we always have this very same argument with our DBA: times are changing, development cycles are meant to be “agile”, and not *everything* can be fine-tuned just-in-case.

After all, this is the reason for having a testing / QA process. When a slow query/transaction shows up… dig for it and fix it!

Nice article.

By: Frank

Frank — Sat, 13 Sep 2008 18:32:23 +0000

njdba, stfu and go back to Oracle developper 2000 you arrogant ass.

It’s not my style but damn it feels good to let it go once in a while.

By: njdba

njdba — Thu, 04 Sep 2008 03:55:23 +0000

Any one who is unaware of SQL and is creating an application should not be in IT. It is that simple. I have been in this business for 20years and this makes me sick. All that is see is garbage and idiots that create stuff that does not work. I consult to clients who hire you idiots and you will find that with the little knowledge you have your stuff will not work.

By: roger

roger — Fri, 25 Jul 2008 00:53:26 +0000

I second the motion for wishing rails would warn when it encountered a potentially bad query :)

By: Green Rails

Green Rails — Tue, 29 Apr 2008 23:20:36 +0000

This is so very true: Rails is pretty damned magic, but sometimes the rubber meets the road.

SQL makes me laugh since a design goal was to be usable by typical business people … yeah, right. I consider myself a black-belt SQLer (arguable, but invite smackdowns from any interested combatant), and despite my >20 years experience with the language, I still find SQL to be the most infuriating and obtuse syntax on the face of the earth (this includes C and C++, as well as perl). Rails insulates us in perhaps 90% of normal cases from the gnarly details. The problem is those 10% of the rest.

I wonder if there’s a need for a Rails “sniff check” of a given controller action, or query? Wouldn’t it be cool if Rails warned “this query takes a really long time — try these things before hiring a $250/hour consultant: 1) use eager loading, 2) check to make sure these columns are indexed (“foo”, “bar”, “fubar”), and 3) learn SQL, you lazy, incompetent so-called software engineer. OK, maybe just 2 things.

We dealt with this issue in the last few days for a really complicated polymorphic query. It is as real as it gets. Rails doesn’t solve all problems … yet.

By: Frank

Frank — Mon, 28 Apr 2008 13:01:13 +0000

@Akita,

*sigh*… enough with this already… this is getting on my nerves. I know the difference between INNER and OUTER. A left outer join includes the rows in the right tables even if there are no match (when it happens the columns in the right table will all be filled with NULLs) while an INNER join only returns the rows “that matches”. In my specific case it just could not happen that a row from the right table does not match a row from the left.

Is this explanation convince you that I know what joins are or do you still need more clarifications?

By: AkitaOnRails

AkitaOnRails — Sun, 27 Apr 2008 17:58:51 +0000

Do you really know the difference between ‘inner’ and ‘outer’ joins? They are quite striking and you can’t replace one for the other with no adequate reasoning. Rails jas both :include and :joins keyword (and :joins accept an array or strings as well) and you have to do the reasoning on what do you want. It seems to me that you don’t know those differences and what do you really want.

By: Neil Wilson

Neil Wilson — Sun, 27 Apr 2008 10:44:21 +0000

You should ignore the database, until you can’t ignore it any longer. I’ve seen the SQL that Rails has generated and figured I could write better by hand. But then I’ve seen the assembler generated by C compilers and reckoned that I could write better by hand. That is not the point though. Ultimately what you are missing here is a tool on the database that *tells* you when you should put an index on something. I’ve alwasy been surpirsed at how poor the tooling is at the database level. Perhaps there is too much ‘hand optimisation’ going on, not too ittle

By: Frank

Frank — Fri, 25 Apr 2008 16:20:39 +0000

Thanks everyone for your comments

The morale of the story for me is that you cannot blindly delegate everything that is “database related” to ActiveRecord or any other O/R mapping tool. Maybe one day tools like ActiveRecord will be so advanced that playing at the database level will not be a necessity anymore … but this time hasn’t come yet. Until then we have to keep an eye on the generated queries from time to time as well as do some optimizing when our app ask for it.

You know what? Before switching to Rails I was a convinced .NET (1.1) developer that used to write all his SQL queries by hand. I remember how much it was repetitive and tedious to do this for every single project. I hated it so much that I made the mistake of embracing ActiveRecord with too much passion when I made the switch to Rails. There is an old saying that love is blind… I should have think about it.