Stored procedures in Ruby on Rails

Question

I am a .net guy with 6 years of experience. Recently I started working on ROR project and realized that stored procedures/sql functions are not being used at all. On inquiring about it I got to know that it is common practice and in general nobody in team writes a sql queries at all, everything is done using ActiveRecord.

I googled about any possible reasons for this but didn't find much information. So I am just curios to know

1. Is it common practice that stored procedures/sql functions are not preferred to use?
2. What are pros and cons of using stored procedures?

Answer 1

Is it common practice that stored procedures/sql functions are not preferred to use?

It is very common, most Rails apps will never need to use anything more than ActiveRecord.

One of the chief philosophies behind Rails is that it's more important to get a working product to market today than it is to get a "fast" product to market 6 months from now. Your product will almost certainly never be popular enough for performance to be a concern. If that does become a problem, you can shore up the performance side of things later, but the immediate concern is to be able to build an app quickly, and to be able to rapidly refactor some or all of it in response to your market.

What are pros and cons of using stored procedures?

They're slower to write and more difficult to change, and therefore front-load your development costs. However, they can be faster to execute.

Answer 2

It might not be the "rails way" to use stored procedures but its also once not "The rails way" to use foreign key costraints, and we all know what a monumentally bad design decision that turned out to be.

So I would take "the rails way" with a grain of salt. If stored procedures work for you, use them.

Heres what I do. Understanding that ORMs often dont really 'understand' stored procedures without slightly more in depth magic, I avoid using it directly, but instead create a materialized view that encapsulates the stored procedure and then presents it as a regular table. Correctly set up, this gives the ORM something it can better understand whilst still leveraging the advantages of keeping database logic inside the layer its supposed to live in, the database, an engine that will always outperform the web framework at data crunching.