Question

Long ago I have learned sql and within the last years of application development I realized I only rarely really play with a real sql console or sql commands at all, especially since I mainly work with rails applications for a while now.

But right now I am working on getting a few Microsoft certifications, so for that I did end up relearning sql from scratch. And by that so many things come to mind that – I have to admit – I have forgotten over all the years. Yes, from a developers view, sql is important, but somehow I didn’t need much of it… like stored procedures, functions, triggers, etc…

While I already found a nice blog from Nasir about using Views in Rails,
I am still wondering if I can use

1. functions
2. stored procedures
3. triggers

in Rails.

Triggers: Of course I wouldn’t need do define triggers within a rails application. I would create them directly on the database management console. I’d just have to remember the things that are ‘automatically’ done. I would like to use those for logging purposes or pre-calculations of quick-access-tables …

Functions: They should be easy to use I would think. Is it possible to add them via the ‘select’-method of ActiveRecord?

Stored Procedures: How would one use those from Rails, i mean they could be valuable if you have several complex queries with multiple joins and calculation-based dependencies. I wonder a) how to call one and b) how to receive the results

Well, if you have more insight to the inner workings of Rails in relation to sql and could point out if these native sql-elements are available for/from a Rails-application it would be lovely if you could point at some Howto’s, Tutorials.

Another thing I am wondering about is the use of foreign keys. Rails doesn’t use them explicitly on the sql-side… would it be useful/helpful to manually add them to the database relations? Or would they hinder Rails’ data access?

Thanks for any response, I am eager to find out what I can do between Rails and Sql to combine them in a maybe more efficient way.

Answer 1

As you will have noticed, and mention yourself: rails does a good job of hiding much of the sql/implementation details.

Still, I believe it is very important to use your sql and database wisely.

Validations

Validations should be defined on your database as much as possible, not only in rails. You define it in Rails to give nice user-feedback if needed. But ultimately you do not know how data gets into the database: some operator can use sql, maybe other programs interface with the database, or more frequent: two rails processes can insert data nearly simultaneously.

Foreign keys

Should most definitely be defined on your database. For rails is not needed, it will write the queries correctly, but this will guard your database against wrong data. This will safeguard your data integrity. If someones deletes a record and another record is still pointing to that, your database will complain.

Indexes

This is even more easily overlooked: create indexes! On your primary key (automatically), on much searched on fields (like name), on foreign key fields !!

Complicated queries

As much as rails helps you when retrieving items, for some queries it is much more efficient to write the query yourself. While I will avoid it as long as possible, find_by_sql is a powerful tool.

And rails is extremely powerful/helpful in treating the result of a find_by_sql as a normal result.

Stored procedures, functions, …

Normally you do not need them when using rails. But there are some very valid cases where they are very useful. For instance, I have created a geographic information system, where we used stored procedures to create various spatial objects. In rails you can directly execute sql using the

YourModel.connection.execute(' .. your sql here .. ')

So even execute stored procedures. It will not be for everyone, but there are some very valid reasons to move work to the database. For example if you have to perform an operation over a whole lot of tables or rows, it could be very efficient to call a stored procedure instead of retrieving all the data, changing the rows, and saving them back. It depends on your problem at hand.

Conclusion

I want to make absolutely clear that Rails nicely abstracts the database away, and for everyday use this is just great. You should define foreign keys, indexes and constraints on your database. For the more advanced stuff like functions, stored procedures, complicated queries: Rails does not stop you from doing anything complicated if needed. One should consider your database as a tool as much as Rails is. But remember:

Premature optimization is the root of all evil. –Donald Knuth

So the options are available, but only use them if it is really necessary.