# DHH Interviewed by MySQL

**URL:** <https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603>\
**Category:** Rails\
**Created:** [February 11, 2006, 5:03am UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603 "2006-02-11T05:03:23Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 11, 2006, 5:03am UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/1 "2006-02-11T05:03:23Z")

</div>

I didn’t see anyone post a link to David’s Interview by Lenz here on the  
list so I decided to post it.

The interview can be accessed here:  
[http://dev.mysql.com/tech-resources/interviews/david-heinemeier-hansson-rails.html](http://dev.mysql.com/tech-resources/interviews/david-heinemeier-hansson-rails.html)

I was very happy to see the interview on PlanetMySQL as just the other  
day I was talking about RubyOnRails on my MySQL blog which is  
syndicated on PlanetMySQL  
([MySQL Consulting and NoSQL Consulting: MySQL DBA: What is your programming language of choice these days?](http://mysqldatabaseadministration.blogspot.com/2006/01/what-is-your-programming-language-of.html))  
and was surprised to see that no one posted a comment about Rails.

I am also very glad to hear about DHH’s future plans of continuing to  
support Rails but not like MySQL AB supports MySQL

On the other hand, being a DBA, I was kinda disappointed at David’s  
following remarks:

“I love MySQL because its fast and easy for the simple stuff. IÂ?m  
entirely uninterested in fancy features like stored procedures,  
triggers, and the like. So I hope nothing is being sacrificed while the  
5.0 series chases these. My advice would be to focus on enabling that  
simple feature set to go higher. Make clustering and other scaling  
techniques even easier. Perhaps baking in support for managing  
partitioned data sets.”

I think stored procedures, triggers and events are very needed in  
MySQL. Hope David is not worried about competition from MySQL 🙂

MySQL users, I would love to hear your opinions on the above  
statement.

Frank

---

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 11, 2006, 5:39am UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/2 "2006-02-11T05:39:08Z")

</div>

softwareengineer 99 wrote:

> On the other hand, being a DBA, I was kinda disappointed at David’s  
> following remarks:
> 
> “I love MySQL because its fast and easy for the simple stuff. IÂ?m  
> entirely uninterested in fancy features like stored procedures,  
> triggers, and the like. So I hope nothing is being sacrificed while the  
> 5.0 series chases these. My advice would be to focus on enabling that  
> simple feature set to go higher. Make clustering and other scaling  
> techniques even easier. Perhaps baking in support for managing  
> partitioned data sets.”
> 
> I think stored procedures, triggers and events are very needed in  
> MySQL. Hope David is not worried about competition from MySQL 🙂
> 
> MySQL users, I would love to hear your opinions on the above  
> statement.

I think it’s more along the lines of keeping everything in one layer.  
See this:

Choose a single layer of cleverness  
[http://www.loudthinking.com/arc/000516.html](http://www.loudthinking.com/arc/000516.html)

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.

Joe

---

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 11, 2006, 7:21am UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/3 "2006-02-11T07:21:50Z")

</div>

On 2/10/06, Joe [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 11, 2006, 9:01am UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/4 "2006-02-11T09:01:25Z")

</div>

Pat M. wrote:

> On 2/10/06, Joe [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

Yeah, I’m redundant in this too. I’ve started using runner scripts more  
to interact with models, but I still do a lot of interfacing via psql  
and phppgadmin and not having data integrity protections in place at  
that level would be playing with fire. They haven’t interfered with  
Rails or gotten in the way - things like validates\_uniqueness\_of happen  
before a unique key in postgresql can generate an error.

Joe

---

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 11, 2006, 7:48pm UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/5 "2006-02-11T19:48:05Z")

</div>

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  
([MySQL Consulting and NoSQL Consulting: MySQL DBA: "Entirely uninterested in fancy features like stored procedures, triggers, and the like" : David Heinemeier Hansson](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:  
[db4free.net blog: "Entirely uninterested in fancy features like stored procedures, triggers, and the like"](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).

Pat M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 13, 2006, 3:23pm UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/6 "2006-02-13T15:23:41Z")

</div>

On 11/02/06, softwareengineer 99 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I think stored procedures, triggers and events are very needed in MySQL.

But the interview was about what DHH thinks, not you 🙂  
He’s said several times before that Rails prefers an ‘application  
database’ to an  
‘integration database’, and he prefers to put that checking in the  
model rather than  
the db.

I suspect most mysql users don’t need those features, or they  
wouldn’t be mysql users.

–  
Rasputin :: Jack of All Trades - Master of Nuns  
[http://number9.hellooperator.net/](http://number9.hellooperator.net/)

---

<div class="post-metadata">

**Author:** ![softwareengineer\_99](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/b782af/32.png) [@softwareengineer\_99](https://www.ruby-forum.com/u/softwareengineer_99)\
**Post date:** [February 11, 2006, 8:16pm UTC](https://www.ruby-forum.com/t/dhh-interviewed-by-mysql/53603/7 "2006-02-11T20:16:49Z")

</div>

A few more negatives for me against MySQL are:

- its licensing (which is confusing - even their reps couldn’t explain  
it).
- its deviance from SQL conformance (which every database has, but  
MySQL’s is much more so).
- its confusing array of database engines (and the uncertainty of InnoDB  
since Oracle’s acquisition).
- its worse performance (for me anyway) due to table locking issues, and  
tables getting corrupted/wedged from time to time.

MySQL can do whatever they want ;). I don’t anticipate ever going back  
as a developer. But choice and competition are good :).

Joe