[Rails] Re: DHH Interviewed by MySQL

[softwareengineer 99]

Thank you Pat and Joe for your comments.
  
  As far as my thoughts are concerned, MySQL needs SP and triggers so it won't loose DBAs to PostgreSQL.
  
  I asked the same question on my MySQL blog  (http://mysqldatabaseadministration.blogspot.com/2006/02/entirely-uninterested-in-fancy.html)  to database administrators and got some very interesting replies:
  
  Markus, a recognized MySQL DBA put the opinions of many MySQL DBA's in excellent words on his site:
  http://db4free.blogspot.com/2006/02/entirely-uninterested-in-fancy.html 
  
  I present a quote from above:
  
  "MySQL simply *needs* features like Stored Procedures, User Defined  Functions, Triggers etc. to be taken serious on the database market! So  long has MySQL been criticized for not providing them - now as they  have been introduced, it would be stupid to criticize MySQL *for*  providing them.
  
  MySQL has a very good chance to get as advanced  as any other database system without losing it's simplicity. I don't  think that performence will suffer a lot in the long run, because  performence optimizations will certainly go on forever and will  certainly overcome the speed decreases that may come from implementing  new features. On the other hand, the other database systems will hardly  ever have a chance to become as convenient to work with as MySQL (of  course, people will always like what they are used to - if somebody has  always worked with another product, he'll be more comfortable with this  than with another - but for new users, MySQL is probably less painful  to start with than the others).
  
  The great thing is - people can  still work with MySQL 5.0 the way that they were used to with earlier  versions. They can decide whether to use the new features, or not. And  that's exactly the right way for MySQL! Continuing to get as advanced  as possible without breaking downward compatibility - where possible  (and useful)."
  
  Another anonymous commenter said that if it wasn't for the SP and triggers he wouldn't have converted from MSSQL to MySQL.
  
  While Rails is a wonderful framework, and Ruby an excellent language, I  believe there is a strong need for these features. Somethings are just  better left to the database. For example, I can think of many  situations, where the DRY can be applied in a better way by using  triggers.

  
  -- Frank
  
Pat Maddox <pergesu at gmail.com> wrote:  On 2/10/06, Joe  wrote:
> I'm sort of coming around to that way of thinking. I switched from MySQL
> to PostgreSQL about two years ago and loved it. But now it DOES sound
> appealing to just handle stuff in Ruby/Rails instead of switching to
> pgsql for sprocs, constraints, triggers, etc. and then handling db
> errors that arise from them.

This is one case where I have no problem being unDRY.  The fact is
that for the apps I write, my Rails app isn't going to be the only
point of access to the DB.  Most of the time the DB is there long
before the Rails app anyway.  So there are two ways of handling things
that need checks, in my mind:

1. Write code to handle errors that pop up from the DB
2. Code the checks into the application itself

Sometimes it's easier and makes more sense to do #1.  In Rails, you
can achieve nearly all of the checks with one line of code, and
everything else with just a few.  You never even get to a point where
the database would create errors.

Anyway this is getting slightly OT.  Basically I just mean that I've
got no problem having two layers of cleverness.  It's necessary for me
to have a clever database, and easy for me to have a clever Rails app.
 The Rails app never sees the DB cleverness, which only exists because
other languages and people that access the DB aren't as bright.

Pat
_______________________________________________
Rails mailing list
Rails at lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails


		
---------------------------------
 Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060211/ea8e8a42/attachment-0001.html