views:

347

answers:

3

I've been developing web applications for a while and i am quite comfortable with mySql, in fact as many do i use some form of SQL almost every day. I like the syntax and a have zero problems writing queries or optimizing my tables. I have enjoyed this mysql api.

The thing that has been bugging me is Ruby on Rails uses ActiveRecord and migrates everything so you use functions to query the database. I suppose the idea being you "never have to look at SQL again". Maybe this isn't KISS (keep it simple stupid) but is the ActiveRecord interface really best? If so why?

Is development without having to ever write a SQL statement healthy? What if you ever have to look something up that isn't already defined as a rails function? I know they have a function that allows me to do a custom query. I guess really i want to know what people think the advantages are of using ActiveRecord over mySQL and if anyone feels like me that maybe this would be for the rails community what the calculator was to the math community and some people might forget how to do long division.

+1  A: 

The idea here is that by putting your DB logic inside your Active Records, you're dealing with SQL code in one place, rather than spread all over your application. This makes it easier for the various layers of your application to follow the Single Responsibility Principle (that an object should have only one reason to change).

Here's an article on the Active Record pattern.

Erik Forbes
would that principle still apply if all your sql was in model classes? that is where the db logic traditionally goes in an MVC architecture right?
ethyreal
thanks, i'll read that
ethyreal
Well, the Active Record pattern entails placing your data access code in your model classes - so, yes it would.
Erik Forbes
A: 

Avoiding SQL helps you when you decide to change the database scheme. The abstraction is also necessary for all kinds of things, like validation. I doesn't mean you don't get to write SQL: you can always do that if you feel the need for it. But you don't have to write a 5 line query where all you need is user.save. It's the rails philosophy to avoid unnecessary code.

MattW.
+1  A: 

You're right that hiding the SQL behind ActiveRecord's layer means people might forget to check the generated SQL. I've been bitten by this myself: missing indexes, inefficient queries, etc.

What ActiveRecord allows is making the easy things easy:

Post.find(1)

vs

SELECT * FROM posts WHERE posts.id = 1

You, the developer, have less to type, and thus have less chances for error.

Validation is another thing that ActiveRecord makes easy. You have to do it anyway, so why not have an easy way to do it? With the repetitive, boring, parts abstracted out?

class Post < ActiveRecord::Base
  validates_presence_of :title
  validates_length_of :title, :maximum => 80
end

vs

if params[:post][:title].blank? then
  # complain
elsif params[:post][:title].length > 80 then
  # complain again
end

Again, easy to specify, easy to validate. Want more validation? A single line to add to an ActiveRecord model. Convoluted code with multiple conditions is always harder to debug and test. Why not make it easy on you?

The final thing I really like about ActiveRecord instead of SQL are callbacks. Callbacks can be emulated with SQL triggers (which are only available in MySQL 5.0 or above), while ActiveRecord has had callbacks since way back then (I started on 0.13).

To summarize:

  • ActiveRecord makes the easy things easy;
  • ActiveRecord removes the boring, repetitive parts;
  • ActiveRecord does not prevent you from writing your own SQL (usually for performance reasons), and finally;
  • ActiveRecord is fully portable accross most database engines, while SQL itself is not (sometimes).

I know in your case you are talking specifically about MySQL, but still. Having the option is nice.

François Beausoleil