CODEWITHSUNDEEP
mysqlruby-on-railsruby
Rio
Rio

Reputation: 14882

Ruby on Rails3 and MySQL query best practices

I'm trying to transition from PHP to Rails and was wondering what the best practices are. I have all the data I need in MySQL and would like to make simple queries and display them using the kinds of niceties afforded by ActiveRecords. I'm familiar with the MVC paradigm and am trying not to rely on my knowledge of PHP, but how, for example, would I be able to do the kinds of things I used to do with:

$query = mysql_query("Select * from table where name = 'blah');

if I already have that data (I can see generating a scaffold if I didn't have pre-existing data). Do I create a scaffold and then import my data into it? or do I write raw MySQL queries in Ruby?

Thanks!

Upvotes: 1

Views: 346

Answers (2)

Yardboy
Yardboy

Reputation: 2805

First, remember that Rails is a web dev framework, not a scripting language like PHP. Ruby is the scripting language. PHP has frameworks as well, but just wanted to make sure you realize the difference between the one and the other.

Most basic and medium-complexity queries in Rails are handled via the ActiveRecord methods and helpers. You'll find that you'll be writing much less actual SQL, as that is generally abstracted away into the framework.

For instance, assuming the name of your model is City, the equivalent of your query in Rails would be:

City.find_all_by_name('blah')

How does this work? When you create a model in Rails you usually subclass ActiveRecord::Base. Built into that class is a plethora of functionality that, for one thing, examines your data table and builds dynamic finders for each of the fields and combination of fields on the table.

Since you already have all the data, you're going to be overriding some of the conventional functionality of Rails in order to get everything working. For instance, Rails assumes by convention that there is a primary key field named "id". Also, Rails assumes that the table is named as the plural form of whatever the model class definition is. All of these things are defaulted by convention, but can be overridden. If you were building from scratch and following conventions, all this would sort of happen as a matter of course.

Based on your question, I think you need to spend some time with some basic Rails reading material and some specific info about ActiveRecord and Rails models, so that you can come up to speed on these major differences between Rails and standard PHP application. If you don't get that straight from the beginning, then you are going to build a lot of PHP-style Rails stuff and you won't be taking full advantage of what Rails and Ruby have to offer. In the end, you'll say "what did I do all that for, it's all the same."

If, instead, you try to start from the Rails Way of doing things, you'll find that Ruby and Rails offer a lot.

Upvotes: 1

sosborn
sosborn

Reputation: 14694

If you are working with an existing database then you are going to have a hard time forcing Rails to play nicely with it. Rails power (some might call it a weakness) is that it favors convention over configuration. In other words, it really expects you database columns to be structured a certain way. Stray from the convention and you lose all the reasons for using Rails in the first place.

When you start a new rails project and use the migrations rails makes sure that the structure is as it expects.

If you are moving an old project to rails then I would strongly suggest writing a function to import that data into a rails-created DB. This will save you a lot of heartache in the long run and will allow you to take full advantage of Rails' strengths.

Upvotes: 0

Related Questions