Bad journalism in the Wired article on Sun buying MySQL

Its hard for me to write an article like this without sounding trite. I’m sure I make many journalistic mistakes in this fine publication. I can’t say “well wired should know better,” since that is tantamount to saying, “I admit no one should read what I say.”

That being said I really think that the wired article on Sun buying MySQL had one really bad flaw. The either misunderstand or misrepresent of facts.

Even with Ruby on Rails and Django gaining in popularity, MySQL remains a popular and common choice of database for today’s startups.

Ruby on Rails and Django are frameworks that can use MySQL or several other databases to store their data. If anything, they would help MySQL gain popularity as many people use MySQL as the database for applications that use that framework. Non technical readers would get the impression that Ruby on Rails would replace MySQL as opposed to complementing it.

The importance of changing ones mind

I do not consider myself an expert on Microsoft SQL server. I prefer Postgresql. However, I am a fan of referential integrity and seek to enforce it at the database level, regardless of the engine. I like my databases to reject invalid data like DMV clerks rejecting incorrectly filled out forms.

When I work with Microsoft SQL server I struggle to enforce referential integrity in the same manner as I do with Postgres. Recently, I wanted to restrict the values that may be stored in a column in a table. A mapping table was not the answer in this case. I thought the answer was to user T-SQL RULES. I implemented a few and prepared to add them to my standard practices. However, about a week later I discovered this nugget on the MSDN:

CREATE RULE will be removed in a future version of Microsoft SQL Server. Avoid using CREATE RULE in new development work, and plan to modify applications that currently use it. We recommend that you use check constraints instead. Check constraints are created by using the CHECK keyword of CREATE TABLE or ALTER TABLE. For more information, see CHECK Constraints.

All of a sudden I needed to unlearn what I had learned. I do this on a regular basis. I consider myself quite stubborn. And I quite value this stubbornness. I will argue my position to the death if I believe it is right. I pride myself on caring about the things no one else cares about, and being able to explain why you should care, if necessary. However, I can be persuaded to change my mind. It’s not so much that I bend or break, it’s more like I recrystallize. Sometimes the transition is instantaneous. Sometime my faith in a concept is broken and I spend a while looking for a replacement. This transition was rather instantaneous as I was presented with a clear message: “What you are using is depreciated and doing it this other way will work better anyway.”

So what is the lesson here? The lesson is simple. Be unwavering in your beliefs, until you have a good reason to change them. Then be unwavering in the new beliefs until they are demonstratively proven inferior.