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