So last post, we established that Rails’ Achilles heel is in scaling the DB. PHP, Perl, ASP, etc. all rely on a database behind the scenes, and all need to scale their DB alongside the rest of the application. Rails often gets the bad rap though.
Why? I can think of only one reason:
Rails lets you write REALLY bad SQL very easily
Which means we wind up with Rails applications that are dying a slow DB
death much sooner than their counterparts that use a different
language/framework. Once again, I’m going to play the “Not Rails’
fault” card. When you have developers with no database experience (and no
desire to learn about them) start developing database-backed web apps,
there’s going to be an major problem! RDBMS’s are extremely complicated and to
build a successful Rails app means you need to have at least a moderate
understanding of what is going on under the hood. Without that understanding,
your Rails app will never scale. But a little bit of study and appreciation for
what is really going on will allow you to quickly spot what is and what is not
acceptable Rails code.
Keeps these thoughts in mind and your Rails app will scream, scale, & [some
other s-word] all the way to becoming the next Twitter.