Databases, Tables, and Rails

For more than a decade, most web applications that used a database used Structured Query Language (SQL) to move information into and out of databases. SQL is a powerful tool for creating and manipulating database structures, as well as for moving information in and out of those structures, but it’s tightly focused on database projects only. You can’t build a complete web application using SQL, so historically developers have written the bulk of their applications in another language, and then made SQL calls against a database. Developers needed to know both SQL and the other language.

Rails changes all of this, taking the position that it’s better to manage data and logic in the same language, in this case Ruby. ActiveRecord abstracts the SQL calls away, though they still exist if you look through the development logs. At the same time, Rake and migrations handle the care and feeding of the database, defining and creating (or removing) tables. You define the tables in Ruby, and call rake db:migrate to make things happen.

If you already know SQL, you have a bit of an advantage when it comes to debugging Rails applications by checking logs and tinkering inside of the database. You may, however, have a disadvantage in getting started with Rails, as Rails pretty much expects developers to put the SQL toolkit away. There may be times when SQL is still actually necessary, so Rails supports a find_by_sql method, but in general, if you find yourself writing SQL, odds are good that you just haven’t found a better way to do things in Rails itself.

You do have one critical choice to make regarding databases, however: which database to use with Rails. By default, since Rails 2.0.2, SQLite is the default database. It’s easy to use with minimal configuration, keeps its information in a single (easily transferred) file, and is widely available.

For many applications, though, you will want to consider heavier-duty options that can handle more simultaneous connections. For many people, MySQL will be the right choice—heftier than SQLite, but not as intimidating as PostgreSQL. Bindings for all three are built into Rails by default, so that part’s relatively easy, and bindings for many other databases are available as plug-ins.

You don’t need to be a database expert to learn Rails. You will want to have administrators who know how to manage, optimize, and backup whatever database system you choose to use for deployment—but those issues should get addressed after you’ve finished learning Rails. You may want to pick up Learning MySQL (O’Reilly, 2006) if you’re new to relational databases and you want to take your knowledge to the next level.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset