Questions Ruby on Rails skeptics ask
[UPDATE: My example for the issue of Rails generating too much database traffic was actually incorrect for Rails v1.0. Luckily, v1.1 introduced bottomless eager loading, which addresses it. I’ve revised the example below.]
If you have been following anything related to web development at all, you have at least heard of Ruby On Rails. If you’re like me, it makes you want to take a flying leap into developing with it. For personal projects there’s nothing to hold you back. However, if you decide to recommend using Rails with a team that doesn’t know much about it, you may run into some questions. If you don’t have some ready answers, the idea will most likely be shot down quickly and left in the dust.
I don’t like using ‘id’ as my primary key name.
Rails is written to expect the field ‘id’ as the primary key to any typical table. Therefore, ‘id’ in a users table would refer to a user id just as ‘id’ in a product table would refer to a product id.
The important thing to know in order to combat this issue is to that while ‘id’ is highly recommended as a primary key, it’s definitely not required. Here’s an example of creating a User model in rails, but telling it that the primary id is UserID instead of ‘id’.
class User < ActiveRecord::Base set_primary_key "UserID" ... end
In addition, by naming your own primary key, you need to assign it a unique value prior to saving anything new to the database. Rails can’t assume your new field is auto-generating or not, so it leaves it up to you to set.
My legacy data doesn’t use that naming scheme.
While
you are free to use any naming scheme you want, Rails is definitely
built to work with its preferred naming scheme. The main thing to keep
in mind, in addition to dealing with how Rails works with your primary
keys, is you may have to add code to inform your objects how they are
related to each other via the database. You could also lose out on
automated functionality like Rails ability to automatically take care
of fields like created_at.
Rails generates too much database server traffic.
Some
people are quick to say Rails makes way too many database calls when
you have a number of objects related to each other in one-to-many or
many-to-many relationships. This is because Rails does not load data
into objects until they are referenced.
For example, if you have an Order and LineItem object where an Order can have many LineItems which in turn are linked to Products you could have something similar to the following code.
for order in Order.find(:all)
puts "Item ordered: #{order.line_item.product_id}
puts "Description: #{order.line_item.product.description}
end
In this example, there would be one database call for the main order, then two calls to retrieve the line item information then the product description. Here’s a much better approach.
for order in Order.find(:all, :include => {:line_items => {:product}})
puts "Item ordered: #{order.line_item.product_id}
puts "Description: #{order.line_item.product.description}
end
Very similar code, but in the latter version the :include attribute tells Rails to preload the line items and products, so it loads up everything in one database call rather than multiple ones. You also have the option of using the find_by_sql function to specify your own custom call.
It’s difficult to find hosting
Finding
a host isn’t much of an issue if you have your own server, but if
you’re looking for a shared host, not every host offers it. The number
grows steadily, though. TextDrive is a leader in Ruby on Rails hosting, but you can find a growing number of hosts on the Ruby on Rails website.
What about performance
Another
frequest concern about Rails is about it’s performance and ability to
scale. While some think it may be good for small and possibly mid-sized
projects, it doesn’t have what it takes for large scale applications. A
lot of this is just knee-jerk reaction. The great thing about the Rails
community is that there is constant work on making things better.
RailsExpress is one website that is focused on Rails performance. In addition to a lot of benchmarks, it also includes a lot of tips for making Rails apps perform better.
TextDrive also has a weblog which has some of their experiences being a host for Rails apps. Optimizing Rails Resource Usage is one and I’m sure they’ll post more.
Just as you’d expect with any framework and language, the better the code you write, the more efficient it will run.
Have other questions?
There’s a number of great places to find more information on how Rails works. A number can be found on the Rails webpage for documentation. The Ruby on Rails API documentation is the most up-to-date resource since it is actually generated from the code itself although it’s more like looking up things in a dictionary.
For a more hands-on, descriptive resource you should really have the book Agile Web Development with Rails. I have to warn you that the first part of the book will get you ready to tear into your first application, but the juiciest information is in the latter part which goes into more details about the underlying Rails framework.
After moving down to the Dallas area, I decided to use 
So that’s why I’m switching to