Robby on Rails: PostgreSQL vs MySQL with Railsthoughts.sort_by{|t| t[:topic]}.collect tag:www.robbyonrails.com,2005:TypoTypo2006-09-05T22:12:43-04:00Robby Russellurn:uuid:601cffecccbe1440db17b9a1483313cc2005-06-18T19:44:00-04:002006-09-05T22:12:43-04:00PostgreSQL vs MySQL with Rails<p>Every once in a while, there is a short debate about using MySQL or PostgreSQL with Ruby on Rails as a database server. If you know me at all, you’ll know that I am a strong proponent of using PostgreSQL. Putting some logic in the database is something that my last few jobs have completely trained me to do.</p>
<p>For example, I try to develop applications under the assumption that it will never be the only interface to the data set that it uses. In a way, I use the database as a part of the model and don’t put the reliance on the model in my Rails application.</p>
<p>For example, take the following example of updating a bunch of records that meet a certain requirement.</p>
<code>
<pre>
Items.find(:all, :conditions => "type_id='2'") do |item|
item.x = "foo"
item.save
end
</pre>
</code>
<p>Is this method quicker than running a simple <span class="caps">UPDATE</span> query on the database? With a smaller data set, this might not be big enough of a concern. But, what if your database has a million rows that meets this criteria? Does it make sense to find them all first and then loop through the recordset one million times and call one million updates? A few problems might occur, one big potential issue is that it is likely that your application might go beyond the timeout of your server and there is no rollback with this transaction.</p>
<p>So, what is the best <strong>Rails-way</strong> to solve this problem?</p>
<p>If the request takes too long and times out, how do you <span class="caps">ROLLBACK</span> your updates automatically? I know how to do this with PostgreSQL (quite simply), but am curious as to how this is addressed by MySQL proponents.</p>
<p>Let’s take another scenario. Perhaps you have a table called <em>foobars</em>. Every time you <span class="caps">INSERT</span> or <span class="caps">UPDATE</span> this table, you want to add a record into table <em>foobarlogs</em> that shows what was added or what fields were specifically changed. With PostgreSQL, you could build a trigger that compares the existing record with the new values and then adds the differences into the <em>foobarlogs</em> table. This might not be something that people encounter, but for some systems, it’s vital that you know when something happened, by whom, and what exactly happened.</p>
<p>Step forward into the future. Client needs a new interface built for desktop usage. Yes, you could use Ruby with wxWidgets and build a nice multi-platform application. In your code, you deal with the same database. With your trigger in place, you don’t need to do anything but call it like you did with Rails.</p>
<p>Yes, MySQL is getting advanced features, but its still a while before you’re going to get to use pl/Ruby for building your database functions.</p>
<p>Wouldn’t this follow more along the lines of the <span class="caps">DRY</span> principal than doing this in the Rails code?</p>
<p>- A curious PostgreSQL-fan</p>
<p>PostgreSQL, all the features you need next year, available last year.</p>
<p>On a side note, here is a <a href="http://article.gmane.org/gmane.comp.lang.ruby.rails/12576">good explanation</a> of how PostgreSQL is useful for certain application requirements.</p><p>Every once in a while, there is a short debate about using MySQL or PostgreSQL with Ruby on Rails as a database server. If you know me at all, you’ll know that I am a strong proponent of using PostgreSQL. Putting some logic in the database is something that my last few jobs have completely trained me to do.</p>
<p>For example, I try to develop applications under the assumption that it will never be the only interface to the data set that it uses. In a way, I use the database as a part of the model and don’t put the reliance on the model in my Rails application.</p>
<p>For example, take the following example of updating a bunch of records that meet a certain requirement.</p>
<code>
<pre>
Items.find(:all, :conditions => "type_id='2'") do |item|
item.x = "foo"
item.save
end
</pre>
</code>
<p>Is this method quicker than running a simple <span class="caps">UPDATE</span> query on the database? With a smaller data set, this might not be big enough of a concern. But, what if your database has a million rows that meets this criteria? Does it make sense to find them all first and then loop through the recordset one million times and call one million updates? A few problems might occur, one big potential issue is that it is likely that your application might go beyond the timeout of your server and there is no rollback with this transaction.</p>
<p>So, what is the best <strong>Rails-way</strong> to solve this problem?</p>
<p>If the request takes too long and times out, how do you <span class="caps">ROLLBACK</span> your updates automatically? I know how to do this with PostgreSQL (quite simply), but am curious as to how this is addressed by MySQL proponents.</p>
<p>Let’s take another scenario. Perhaps you have a table called <em>foobars</em>. Every time you <span class="caps">INSERT</span> or <span class="caps">UPDATE</span> this table, you want to add a record into table <em>foobarlogs</em> that shows what was added or what fields were specifically changed. With PostgreSQL, you could build a trigger that compares the existing record with the new values and then adds the differences into the <em>foobarlogs</em> table. This might not be something that people encounter, but for some systems, it’s vital that you know when something happened, by whom, and what exactly happened.</p>
<p>Step forward into the future. Client needs a new interface built for desktop usage. Yes, you could use Ruby with wxWidgets and build a nice multi-platform application. In your code, you deal with the same database. With your trigger in place, you don’t need to do anything but call it like you did with Rails.</p>
<p>Yes, MySQL is getting advanced features, but its still a while before you’re going to get to use pl/Ruby for building your database functions.</p>
<p>Wouldn’t this follow more along the lines of the <span class="caps">DRY</span> principal than doing this in the Rails code?</p>
<p>- A curious PostgreSQL-fan</p>
<p>PostgreSQL, all the features you need next year, available last year.</p>
<p>On a side note, here is a <a href="http://article.gmane.org/gmane.comp.lang.ruby.rails/12576">good explanation</a> of how PostgreSQL is useful for certain application requirements.</p>