I understand that MySQL as a company wants to recruit paying customers. However, as a community user I have a hard time finding what I want on the MySQL website. Today’s frustration is brought to you by trying to find the documentation.

Go ahead, hit http://www.mysql.com. From there, where do you go to find the documentation?

It’s not Services, not even Services -> Support.

According to Products, the community server is not even a product. How is a potential new user, who wants to learn about MySQL, supposed to know a community version exists? Here are the products listed on the Products page:

MySQL Enterprise
MySQL Enterprise Monitor
MySQL Cluster
MySQL Embedded Database
MySQL Database Drivers
MySQL Database Tools

Where’s “MySQL Database” on that list? A website user basically has to know what they’re looking for, since that page does not help find “the mysql database”. You can guess it’s the “MySQL Enterprise” — but you’d be wrong. Imagine if you’re a person unfamiliar with MySQL who has been told “go to the MySQL website and get the free version of the database, it’s great!”

OK, OK, I know, you’re saying “click on Downloads”. Which takes me to the “choose which version you want to download.” OK, nice for newbies, but really annoying for the experienced. Why aren’t the links to download at the top, with the explanations just underneath? A newbie would be presented with the links, think “I don’t know which to choose!” but then see that the descriptions are just underneath. An experienced user can just click and go.

This of course is made even more silly when you realize that the community download link simply scrolls down. Yes, that’s right, the community downloads immediately follow that chart of explanations. Which means that in the current state, when the link is at the bottom of the chart, the link points you to the next line. If the link is at the top of the page, at least there’s a reason for it — to scroll down past the explanations.

Now recall that the exercise was to find documentation. There is no way to download the documentation here.

I am a non-paying user, not a developer. Going to the “Developer Zone” is not intuitive for me. However, that is exactly where I need to be:

* DevZone
* Downloads
* Documentation
* Articles
* Forums
* Bugs
* Forge
* Blogs

Given that list of topics, why on earth is this section called the “Developer Zone”? (it’s a rhetorical question!) Sure, if I’m a software developer I might think it’s useful to me. On any other website “developer zone” is relegated to advanced users, or folks using some different part of the product than what most people use (think Apple’s Developer Connection).

Take a look at that list. On any other website, it would be under “Support” or “Help” or “Learn”.

No wonder folks have no idea that the forums exist, much less the Forge or Planet MySQL. If I was a new user to MySQL and I wanted to find the documentation, I’d be very unhappy.

Heck, I’m very unhappy anyway — what kind of company has a huge community of people supporting each other and contributing back to the company, and does not give people an easy way to find the community?

Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.

• Presentation


• Application


• Business Logic


• Persistence (also called Storage)

The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:

A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.

It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it?s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.

I will call this merged business/application layer the “functional layer.”

The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.

“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”

Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.

This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].

This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(’Sheeri’,'hair color’,'blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.

For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.

The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.

Thoughts?

I have already blogged about this keynote at http://www.pythian.com/blogs/948/liveblogging-who-is-the-dick-on-my-site.

If you are interested in actually seeing the video, the 286 Mb .wmv file can be downloaded at http://technocation.org/videos/original/mysqlconf2008/2008_04_17_panelDick.wmv and played through your browser by clicking the “play” link at http://tinyurl.com/55c5ps. This is not to be missed!

In a despicable business practice, I received a message from a PR Firm representing Ingres. Now, I even wrote about the controversy that seems to have swept the open source community; but even my writings were not completely factually correct — I wrote that even if online backups were closed it was not necessarily the worst thing in the world. The actual parts of the online backup that are not open source and free are compression and encryption — that is all.

So really, we are talking about a very small part of backup. The last I saw most people used their own compressing (ie, | gzip -c) and encryption for backups. And honestly, I would rather use tried and true compression and encryption than something new that MySQL comes up with, so I do not even see most people wanting compression nor encryption.

But that’s besides the point. If Ingres thinks they can win customers over by swooping in when a controversy is happening, they are way more evil than I would ever have guessed. It’s not good business practice to do this kind of thing — it is cold, calculated, uncalled for, and just plain wrong.

As for my comments — firstly, MySQL did not make any particular “announcement”, and secondly, MySQL is already losing “feedback and contributions on its products from a large group of users in the community” because it does not have an easy way to get community patches committed to the source tree.

There is so much else that bothered me about the e-mail I received, so I will just copy it here for full context for readers:

Subject:  Ingres' Thoughts on Today's MySQL Announcement and What it Means for the Open Source Community

From:  Lindsey Pappas

Date:  Apr 15, 2008 5:33 PM

Hi Sheeri,

 Did you see MySQL ’s announcement on new features in MySQL Enterprise version of its product? This is interesting news for the open source community, as it appears that MySQL is moving away from true open source towards a proprietary model by not providing the same features in its community version. Ingres is a a leading provider of open source database management software and support services and views the news as the loss of a true competitor in the open source space.  By doing this, MySQL will lose feedback and contributions on its products from a large group of users in the community. Costs will go up and quality will go down.

 Ingres is a believer in the true open source of its products.  I can put you in touch with an executive at Ingres to hear thoughts on the news and what MySQL’s announcement means for the future of the open source community, including comment on:

·         The benefits of open source solutions that are identical between community and enterprise, functionality should not differ between products, cost or version.

·         The importance of an online backup component for mission critical applications.

·         In a community where everyone benefits from the valuable contributions and feedback on new developments and innovations from other players, MySQL?s move away from open source is a loss for the open source community.

Please let me know if you?d like to connect in the next day or so to discuss MySQL?s announcement and where the open source community is headed.

Thanks,

Lindsey

Lindsey Pappas
Atomic Public Relations
8 California Street
San Francisco, CA 94111
(415) 402-0230
lindsey@atomicpr.com