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 ...
Get Learning Rails now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.