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

By: Dan

Dan — Thu, 24 Apr 2008 14:58:59 +0000

How can we be so unrespectful about databases? I’ve been working in Rails since 1 year and never I looked at the indexes that are created (or not). Shame on me…

By: Shai

Shai — Thu, 24 Apr 2008 15:21:14 +0000

Nice article. I’m working with databases full time so I definitely appreciate indexes and using correct joins. Jamis Buck covered this issue a while back here (should be mandatory reading for rails developers) http://www.therailsway.com/2006/11/21/tracks-part-4

By: Rowan

Rowan — Thu, 24 Apr 2008 15:43:34 +0000

Some related reading, I did a presentation on ActiveRecord gotchas with include/select/find_by_sql. Not only joins, but limiting your selects are really important here http://work.rowanhick.com/2008/02/12/how-to-avoid-hanging-yourself-with-rails/

By: Robin Watson

Robin Watson — Thu, 24 Apr 2008 16:17:56 +0000

It’s very true that ActiveRecord causes too many Rails coders to not think about the database. ActiveRecord can be painfully slow

One question: Is it right that in many cases, switching an outer join to an inner join could cause different data to be selected from the database?

By: kabari

kabari — Thu, 24 Apr 2008 16:34:59 +0000

@Robin: yes, they can provide different results. Here’s a pretty good write up on the subject: http://www.wellho.net/mouth/158_MySQL-LEFT-JOIN-and-RIGHT-JOIN-INNER-JOIN-and-OUTER-JOIN.html

This is why I like the stuff that RedHill on Rails has. Allowing me to add my indexes and foreign key associations in my migrations.

By: Clemens Kofler

Clemens Kofler — Thu, 24 Apr 2008 17:19:24 +0000

You seem to have run into the same problem like many other developers. Just because you’re doing Rails, that doesn’t mean you don’t have to understand the works _behind_ Rails. Every web developer working with any programming language or framework should be at least familiar with the basics of joins (i.e. differences between outer and inner joins), basic database optimization (like using indexes) and how to track inefficient queries (using EXPLAIN in MySQL, for example).
Read. Learn. Remember.

By: Railers Need To Stop Not Caring About The Database : Hendrik Mans

Railers Need To Stop Not Caring About The Database : Hendrik Mans — Thu, 24 Apr 2008 17:41:50 +0000

[…] other news, most Rails apps are slow because the developers are ignorant of database basics. Not slamming the blog’s author, but it is a good example of how easy it is to mess up a Rails […]

By: Joe Grossberg

Joe Grossberg — Thu, 24 Apr 2008 17:43:07 +0000

On the other hand, you lose a lot of the ActiveRecord advantages if you pay *too much* attention to the database. Don’t optimize prematurely. But yeah — if there’s slowness, tail the db log and look for inefficiencies.

By: Optimizing ActiveRecord :includes with :select | trapdoor1

Optimizing ActiveRecord :includes with :select | trapdoor1 — Thu, 24 Apr 2008 17:51:55 +0000

[…] have just read two posts (here and here), both of them discussing the sometimes formidable challenges faced when attempting to […]

By: typicalrunt

typicalrunt — Thu, 24 Apr 2008 18:02:50 +0000

After reading this post and seeing the comment “don’t optimize prematurely”, many database developers and seasoned programmers are shaking their heads right now.

I’ve seen many a code (in rails, python, or any language for that matter) that uses an ORM library which doesn’t generate efficient SQL. This is fine, as long as those developer using the ORM know what the generated SQL is and how to make it more efficent. The guys from iBATIS have a good idea of how to interface with a DB, but it’s missing the glamour of ActiveRecord. Sometimes custom SQL is the best option, regardless of how ugly it makes the ORM/ActiveRecord code look.

By: Pazu

Pazu — Thu, 24 Apr 2008 20:25:14 +0000

Rails DOES care about the database, in fact Rails cares more than most other web frameworks out there. ActiveRecord is designed to keep you CLOSE to SQL, so you never forget that in the end that’s what being executed.

You should think of ActiveRecord as something to help you construct and issue SQL commands that would be otherwise complex and troublesome to write, not as an excuse to not know anything about your database.

By: NIck Fessel

NIck Fessel — Fri, 25 Apr 2008 01:15:58 +0000

Rails is a calculator, and the database is math. Teach a child math before giving them a calculator!

By: florentin

florentin — Fri, 25 Apr 2008 03:40:29 +0000

I got exactly the opposite from you I do a great merise relationship model (i try …) but a sh***s rails models…
I learn merise with a teacher that doesn’t know ruby nor rails …(and who think c# THE programming language ..)so i start with complicated diagrams but poor(inefficient) relation in my apps.
well sometimes it’s hard to make rails/relationship diagrams match…

By: Michael

Michael — Fri, 25 Apr 2008 12:33:06 +0000

Indexes are good for more than speeding up SELECTs, as I’m sure you’re aware. One ActiveRecord feature bit me pretty nicely. The validates_uniqueness_of constraint is definitely not guaranteed as the skateboard book says on p. 369. Further, it does a SELECT every time it does an INSERT. This can be costly. A “guaranteed” way to enforce uniqueness and to help with efficiency is to create a unique index on the field(s) in question at the database level. You’ll need to trap the database error yourself though. YMMV.

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.

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: 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: 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: 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.