Locating the Real MySQL

An anonymous reader writes "In a blog post, Patrick Galbraith, an ex-core engineer on the MySQL Server team, raises the question: "What is the official branch of MySQL?" With Monty Widenius having left Sun and forked off MySQL for MariaDB, and Brian Aker running the Drizzle fork inside of Sun, where is the official MySQL tree? Sun may own the trademark, but it looks like there is doubt as to whether they are still the maintainers of the actual codebase after their $1B acquisition of the code a year ago. Smugmug's Don MacAskhill, who is the keynote at the upcoming MySQL Conference, has commented that he is now using the Percona version of MySQL, and is no longer relying on Sun's."

Comments

PostgreSQL

[mlwmohawk]

http://www.postgresql.org/

Just saying.

Re:PostgreSQL

[Reality Master 201]

Hey, maybe people have a reason to use MySQL - a product that only supports that db, or developers who aren't particularly familiar with what relational databases are supposed to be like.

Re:PostgreSQL

[LWATCDR]

It really is a very good database. I just hope more projects start using it. And that more hosting companies will as well.
I am pretty sure that that MySQL still has better client slave replication "Like Slashdot uses" than Postgres. But I could be wrong.

Re:PostgreSQL

[VGPowerlord]

Hey, maybe people have a reason to use MySQL - a product that only supports that db, or developers who aren't particularly familiar with what relational databases are supposed to be like.

I don't know why this is marked as Funny... there are far too many programs or even webapps (PHP ones in particular) that only work with MySQL.

Re:PostgreSQL

[__aasqbs9791]

Why do you like it so much? Is it faster with large datasets? Does it support backups/replication/some other great to have feature?

I'm pretty familiar with MySQL, but I've been thinking about branching out to PostgreSQL lately as I've seen a few jobs that prefer it. I'd just like some real reasons why I should prefer it, as well as any "gotchas" that might be important for a MySQL user to know. I've never had a problem with MySQL, but most of the projects I've used it on have been fairly small.

Re:PostgreSQL

[larry bagina]

ACID :).

I prefer postgresql because of the stored procedures, triggers, rules, plpgsql, etc.

MySQL 5 sort of has some of that now, but when I las t used it (MySQL 4), I ended up trying to half-ass implement that stuff client side. Postgresql makes it easier to do it right.

Re:PostgreSQL

[Anonymous Coward]

Here are some sites that might help.

Re:PostgreSQL

[rackserverdeals]

One of the reasons I like PostgreSQL is it is more like Oracle.

If you're doing a migration from Oracle, especially one that has a lot of pl/sql functions. Here's some good advice for converting pl/sql to pl/pgsql.

Also, going from PostgreSQL to Oracle seems easier as well. With PostgreSQL you can use more Oracle like features so if you need to move to Oracle, you can take advantage of some of it's advanced features instead of migrating simple tables and sql statements.

Sun was actively involved with PostgreSQL before they bought MySQL. I was really dissapointed with their decision, especially at the price.

My guess is they weren't really buying MySQL for the technology, they were buying it for the community. Overnight, a ton of MySQL users and developers were part of Sun's open source community. Building communities takes time and Sun was having a hard time doing it with some of their projects.

All it seems they did though is fund MySQL forks. Kinda messed up for the MySQL developers to do that but we don't know all the details.

$1 billion dollars could have funded a lot of improvements to PostgreSQL better clustering, replication, visual tools, and more. A better PostgreSQL could hurt Oracle more than buying MySQL. After Ellison announced he'd be moving his developers from Solaris workstations to Linux workstations, it could have been a nice comeback.

It also seems that the switch form solaris to linux might not have been developer driven. Even MS knows you have to keep your developers, developers, developers happy.

Re:PostgreSQL

[carlzum]

The latest version of each have brought the two much closer in terms of performance and features. Historically, MySQL has been regarded as faster for simple querying and DML statements, but lacked full ACID compliance. PostgreSQL supported more advanced features like a PL/SQL style procedure language, transaction support, and data compression.

Today, the big difference is PostgreSQL is considered better on higher-end hardware with concurrent I/O support and better multi-core support. MySQL is considered better on clusters of lower-end hardware. There is a Wiki comparing the two in much better detail.

Personally, I work with both in large production systems and can fill a few pages on likes and gripes. I'm on MySQL 4.1, so concurrency is a concern, and PostgreSQL's replication is a pain. Unless you're trying to solve a problem MySQL can't satisfy, I wouldn't switch for the sake of change. Your time is probably better spent upgrading to MySQL 5.1.

Re:PostgreSQL

[thatskinnyguy]

Amen. PHP/MySQL has been a defacto standard for how long now? I mean, it just works. And if there is a problem, it's well-documented. So ubiquitous, well-documented and free... Why would I choose use anything else?

Re:PostgreSQL

[Anonymous Coward]

ubiquitous, well-documented and free... Why would I choose use anything else

Because it's of higher quality?

Re:PostgreSQL

[DiegoBravo]

> Why would I choose use anything else? ... Because a lot of people thinks that foreign key constraints are the best and most important way (after primary keys) to secure the consistency of the application's data.

Of course, that people probably never wrote a dozen of lines of code, so they never realized that the programmer has one thousand of more powerful ways to corrupt all the application data (sadly, databases are not immune to code bugs despite any imaginative constraints.)

BTW, that same people never will understand that there exists some thing called innodb; but to be fair, it is a shame that MySQL yet defaults to the isam (i.e. not enforcing FK) engine.

Re:PostgreSQL

[Jack9]

And others know any (Wiki) article, online, is equally suspect.

Re:PostgreSQL

[greg1104]

The Oracle pl/SQL -> PostgreSQL pl/pgSQL link you suggested was from PostgreSQL 7.1, pretty ancient at this point. PostgreSQL 8.3 Porting from Oracle is a current resource.

Re:PostgreSQL

[coryking]

And if there is a problem, it's well-documented.

Good luck finding it. MySQL has horrible documentation. The whole structure of it is a mess.

Plus, when you say "and if there is a problem, it is documented". Yeah, that is great, but most of the "well-documented" problems are long-standing bugs for insanely stupid shit.

It does make me laugh though, because honestly, I agree that mysql is well documented. Every random question I google for usually has a hit. And funny enough, the top listing is usually a page here--failing that, at least on the first page of results.

Why would I choose use anything else?

Because you know better.

Re:PostgreSQL

[rackserverdeals]

Early on, PostgreSQL focused on complete implementation and correct behavior over speed, then worried about adding speed later. MySQL focused on speed, and worried over correctness and completeness later. Since then, PostgreSQL has sped up a lot, and MySQL has shaped up in implementation completeness. But it won't surprise me if PostgreSQL still has a few extra features.

This comparison of PostgreSQL vs MySQL is on PostgreSQL's wiki but it seems very fair.

The most interesting bit is this:

It is worth observing that the database engine is part of the core of PostgreSQL, whereas InnoDB is a dual-licensed product presently licensed from Oracle Corporation. It is uncertain how Oracle may alter InnoDB in the future as they act in competition with MySQL AB, whereas PostgreSQL has no such conflict of interests. MySQL AB has been working on a new database engine core called Falcon in order to free themselves from this situation, but historically developing a database core engine that is both fast and reliable has required many years of work and testing before a mature product suitable for production use is available. Initial benchmarks suggest Falcon has plenty of rough edges that need to be addressed.

The forking of MySQL is going to split resources and creating that replacement for InnoDB may take longer.

Re:PostgreSQL

[rackserverdeals]

I don't know why this is marked as Funny... there are far too many programs or even webapps (PHP ones in particular) that only work with MySQL.

The problem is that the Funny mod can't differentiate between when someone is laughing with you or at you.

Re:PostgreSQL

[wolfie123]

Why do you like [PostgreSQL] so much?

The reason we use PostgreSQL instead of MySQL at work is mainly because the JDBC drivers for MySQL are GPL licensed, while Postgres' isn't.

Re:PostgreSQL

[Mark Round]

Well, not natively. But there are a bunch of 3rd party replication/clustering products that do that for you. The original thought was that a replication engine should be pluggable as everyone has different requirements, so it shouldn't be in the main database. However, they've relaxed that stance a little - there was an announcement of an effort to build a native replication engine being in for 8.4, but it looks like it won't make it until 8.5 or so. But they are working on it (and they recognise something like MySQL's replication has attracted a lot of developers so I would imagine something along those lines).

Re:PostgreSQL

[Lord Bitman]

why should he modify his language in support of idiots who mis-use terms, especially when the site name (wikivs.com) is right next to the link?

Re:PostgreSQL

[mlwmohawk]

Why do you like it so much? Is it faster with large datasets? Does it support backups/replication/some other great to have feature?

Yes.

Here's one: On a large table, on a live site, create or drop an index. MySQL locks up until its finished, PostgreSQL keeps working.

Re:PostgreSQL

[growse]

I'd argue that there's a gigantic chasm of difference between the headaches you get with installing and configuring Postgres to those you get when installing and configuring Oracle. I've done both. I'd only happily do one of them repeatedly.

I'm also curious as to what exactly is more difficult about Postgres compared with MySQL to install? Maybe I've done it so many times I know what I'm doing, but there seems little difference.

Re:PostgreSQL

[Dragonslicer]

To expand on that a bit, MySQL as a whole is GPL, while PostgreSQL is BSD licensed.

Re:PostgreSQL

[MinistryOfTruthiness]

The "headache" is that it's secure by default and you need to edit pg_hba.conf (allowed IPs) and postgresql.conf (listen port) to get it opened up to the world. In other words, people want it to be insecure, and it takes effort to make it so. Sad that editing a line in two different config files once during the life of a database is now deemed "a headache" and a major reason not to use that database.

Maybe they're having a hard time finding it in Synaptic? Here's a hint, guys: it's sorted "alphabetically" and there's a search button on the top.

Otherwise, there are absolutely NONE of the headaches that come with Oracle: the licensing, the immense resource requirements, the bloated platform it brings along with it (several hundred megs for a database?! WTF?) It really is the best of Oracle without Oracle's headaches.

Oh -- and the killer features for me? ACID, MVCC, plpgsql and plperl, user-defined functions long before MySQL had them, a user and developer community that is second to none, a strong focus on doing it "right"...

Re:PostgreSQL

[MinistryOfTruthiness]

Are you kidding? PG has incredible docs.

Go to their site (http://www.postgresql.org) and click "Documentation." Heck, I'll do it for you: http://www.postgresql.org/docs/

Witness online documentation (with and without comments!) for the last FIVE server versions. Start poking around in that documentation and it doesn't take long to realize that documentation is far from "lacking."

Re:PostgreSQL

[quantum bit]

When was that? PostgreSQL has been using MVCC for as long as I can remember (as least since 6.0+, probably earlier), which is the same type of concurrency control used by Oracle. The implementation is a little different, but the effect is the same. Much more efficient than the locking method used by MySQL and MSSQL until fairly recently (SQL Server 2005 and InnoDB use MVCC).

Re:PostgreSQL

[dgallard]

> My guess is they weren't really buying MySQL
> for the technology, they were buying it for
> the community.

Good point. AND, that is precisely why technologies
such as Perl and MySQL succeed so well in spite of
suboptimal even awkward design within the product.

First, beware of posters here, including me,
that, as with religious text editor debates, tend
to like what they know, and what they have used
the most. That being said...

I remember the first time I saw the Perl Book (way
back when) my reaction after a 30 minute skim read
was "there is no way I am going to use a language
that has a manual this thick and is so out of touch
with computer science". Yet now I love Perl and
am kind of proficient with it. Why? Because the
community that develops it not only cares about
the community, they make things easy to do from
the system point of view: installing, providing
examples, being pragmatic about over overloading
constructs in just the right way so that one can
get things done and get them done quickly, etc.,
etc., etc.

Isn't it nice that '', NIL, and 0 all tend to
have the same semantics in context in MySQL,
for example? That on the command line, you
can enter a comment with //, --, or /* ... */?
Those are trivial examples but they illustrate
the common sense pragmatism that the MySQL
designers put into their system. It just makes
life nicer for the user.

MySQL designers and community make the right
choices to support the fostering of the language.
Postgres (I refuse to use the new name PostgreSQL
which is a cheap cop out and attempt to leverage
on the success of MySQL by copying the idea of
the name) and Oracle do not share that basic
thrust of making things simple to use at the
system level. Oracle was first though, and
is "real", very real. And very solid. So it
continues to dominate based on sheer user base
in critical applications and the complexity of
building a complex solution in the RDBMS space.

Don't get me wrong, if I had my druthers, I would
use Postgres. But, for same reason I went with
Linux and the world went with Intel chips over
Motorola, it's all about pragmatism and just
getting things done. I started looking for a UNIX
on a PC back in about 1985. When FreeBSD came out
I tried it. It was only when Linux, due to the
sheer pragmatism of its community attracted so
many followers and I noticed that friends of mine
in the research community were going with it that
I made the decision to do likewise, and have not
looked back. Same reason I stuck with Red Hat
after giving SuSE a sold try a few years ago.

MySQL is to use and, more importantly, EASY TO
START USING.

Disclaimer: I have not used PostGres very much at
all. I have and do use both Oracle and MySQL a lot.
I tried PostgreSQL (OK, I'll call it that)
enough to be frustrated by its lack of community
and approachability. I am sure that if I applied
myself on some serious project, I could become a
fan of PostgreSQL. I might yet do that if the
right opportunity arises. Buy MySQL now HAS the
community and, like with Windows, people have to
make a choice that is swayed by the sheer momentum
since, after all, you need community. It takes
a village, as someone once put it.

Re:PostgreSQL

[Eivind Eklund]

Why do you like it so much?

It works by default.

MySQL has, in my experience, a tendency to weirdness. Examples abound:

• Inserting an invalid value into a ENUM creates an empty string (even if that is invalid for the ENUM)
• Inserting too long strings leads to truncation rather than an error
• Inserting empty strings into numbers lead to 0 rather than an error (see a pattern here?)
• On out of disk, MySQL corrupt indexes (depends a bit on version; newer versions are better)
• Constraints are not fullfilled by default. To make a true foreign key constraint in MySQL, you have to
  1. Request a special table type (usually InnoDB)
  2. Have the table type enabled on the server (otherwise, MYSQL will silently fall back to MyISAM and not enforce your constraints)
  3. Add the constraint to your table specification
  4. Have a suitable index for use by the constraint, or the constraint will be silently ignored.
• Replication can silently fail, while looking like it works fine. (This happens when there is a firewall between the master and slave that sometimes drop connections; the slave will believe all is fine even when it does receive any events for weeks.)
• Subqueries are treated as second class citizens. First they weren't there, then they refused to work in a lot of situations (not allowing the same key used both in the subquery and the outer query), then they had horrible performance for what should be (from the view of the optimizer) simple joins. I think that's still the case, but haven't been involved with query optimization in MySQL for over half a year.

These are just off the top of my head, and not all that are there. MySQL has way more non-functionalisms. All of the above have impacted development/stability for projects I've been involved in.

So - I like PostgreSQL because it works. Better performance for complex queries is nice - but I'm mostly interested in the fact that it for the most part just works by default.

Eivind.

MariaDB link is incorrect

[Matchstick]

The MariaDB link should be http://askmonty.org/wiki/index.php/Main_Page

Re:MariaDB link is incorrect

[grantek]

If they can't find the real MySQL, sounds like they need a unique identifier with an index...

Selling an open-source software business?

[MrEricSir]

This calls into question whether it's viable to sell a business based on open-source software.

What did Sun buy exactly? Sales and support?

Re:Selling an open-source software business?

[syousef]

What did Sun buy exactly? Sales and support?

A bridge!

Hello Mr Sun CEO, I have a bridge here to sell you! Best deal you'll ever make. Pinky swear.

Re:Selling an open-source software business?

[Ungrounded Lightning]

This calls into question whether it's viable to sell a business based on open-source software.

I was under the impression that MySQL operated with a full-featured, proprietary, licensed, commercial version getting immediate upgrades and support, plus a less-featured open source version with releases of code (ported?) from the full-featured branch that ran some months behind the for-pay version.

If that's right, I'd say Sun bought the whole shebang, including the code and customer bases for the licensed deluxe version, not just the open-source codebase, trademark, and employment contracts of a room full of engineers.

As for the viability of "sell[ing] a business based on open-source software", why don't you bring that up with the stockholders of Red Hat? B-)

Re:Selling an open-source software business?

[tsalmark]

For $1B I'd say it's plenty viable to sell an open source business. Buying one on the other hand may be open to debate.

Re:Selling an open-source software business?

[ximenes]

For the database server itself, there is no difference between MySQL Community Edition and MySQL Enterprise Edition besides the release schedule. The community edition (aka the regular one everyone uses) has been pared down to 4 releases a year, which are cherry picked from the enterprise releases.

However, the source is completely available for the enterprise releases, and you are able to compile and install them yourself. This is what Percona is doing, for instance (plus some other patches).

With that said, MySQL has other software that comes along with the enterprise edition that is not open sourced to my knowledge. A query analyzer, monitoring, and other goodies. Personally I prefer to find their equivalents in the open source world, but I'm sure some people buy and use these packages.

Not a good precedent

[syousef]

I don't have any idea what the politics behind all this is, nor do I have enough interest to look it up, but it seems to me that if a company pays $1B for code, then it forks left and right and they're left with nothing but yet another version, that's not going to exactly be a good advertisement for investing in open source. While this outcome is much better than a closed source application being killed off, it still would have been much better if differences could have been worked out and Sun had something for their money.

Re:Not a good precedent

[jvillain]

Actually the message it sends is you can not take control just by buying out one piece of the open source world. For the record Sun is going through the same thing with Open Office. Sun really doesn't understand open source.

The official branch is where ever the big distros decide to pull from.

Re:Not a good precedent

[turbidostato]

"The official branch is where ever the big distros decide to pull from."

May I offer a rewrite?
The official branch is where ever the knowledgeable gurus decide to push into.

Allow to say:

[drolli]

While i am *not sure* of the details, i am pretty sure that SUNs lawyers did not forget to make very definite regulations for maintainers leaving, forking of etc. As far as i undrstood, sun bought the code *and* the rights. As many people dont understand GPLed code still has an owner. Independent of that mysql may still be a trademark.

So the standard (GPL) way is to rename the project and add the staement that you modified it which *somehow* makes it different from the "official" branch (to define that, that is the branch which does not carry the notice that it was modified and which is published under the prior, maybe (tm)ed, name).

Enough already!

[Wee]

And now pretend that you are, like many thousands of other people, hosted in a place that doesn't offer it. Or run software which can't talk to it. Or have staff who aren't trained in its use or upkeep. Or... a hundred other things.

Enough with the knee-jerk elitism. MySQL is just fine for quite a lot of tasks, and the article isn't about the religious battle between DB packages.

-B

Re:Enough already!

[digitalunity]

It's not a religious battle, it's about using the best tool for the job. MySQL may be very easy to setup, but just fyi, PostgreSQL is a snap to set up now on Windows or Linux.

Looking for reasons to use PostgreSQL?
Much better index support.
Kerberos or LDAP access controls.
Better native Unicode support.

If you're hog-tied to MySQL because of your software, well so be it. But if you have a choice, the winner should be fairly obvious.

Re:Enough already!

[einhverfr]

Actually the subject is how your data is supposed to be used.

MySQL users see the database as a program persistance layer. I am not sure WHY they are using something that pretends to be a relational database, but they are. It is the single-app approach (one app, one database).

The PostgreSQL crowd sees data and application as being separate issues. The data in theory should be able to be managed in any of a hundred different applications, all hitting the same database, without causing the nightmares in QA that this sort of thing creates in MySQL.

So is the program what is important? Or is the data there to be used by many programs?

MySQL works OK for one-app databases and many people think that is all that is needed. It breaks down outside that area, however.

Re:Enough already!

[iluvcapra]

An "Elite" is a person or group that have superlative skills an ability, and are granted enhanced social status on account of this, to wit "I'm good at what I do therefore I should lead/be popular/be recognized." This is probably tolerable.

"Elitism" is a dysfunction where a person or group uses enhanced social status to asserts superlative skill and ability in order to justify their social status and to exclude others. "I'm popular/leading/recognized therefore I am good at what I do therefore I should lead/be popular/be recognized and there ain't no way those dirty punks over there are as good as us, after all they aren't as popular."

Re:Enough already!

[coryking]

The RMDBS crowd sees data and application as being separate issues.

You forgot to broaden your scope. Otherwise, you are correct.

Your database is almost literally your company. It should reflect your way of doing business--any moderately skilled developer should be able to walk into an orginization they know nothing about and using only the database schema, infer pretty much what the company does, and how it does it.

You can always fix flawed software design, but it is almost impossible to fix a flawed database design. Do your database wrong, the growth of your company will be hindered. Do it right, and your company will flourish. No joke.

Re:Enough already!

[coryking]

but degrading everyone else that has no interest in using it is.

It isn't degrading. When you clean up enough messes left by people who have no business touching a database, it gets fustrating. Especially when things like this are said:

how exactly does innodb not take things like referential integrity and error reporting seriously?

Because InnoDB is only half of MySQL. InnoDB doesn't do fulltext search. If you want fulltext, you gotta go MyISAM. Guess what happens to your cute, cozy referential integrity when half your tables are InnoDB and half are MyISAM? Bye bye! And error reporting? What error reporting? The part where it doesn't tell you "bye bye referential integrity!" and rolls back half your transaction and commits the other half? Or did you mean the part where it automatically adds default values to fields you set not null*? Or were you talking about the part where it thinks invalid dates are valid and doesn't throw an error? Or are those examples only good for Fortune 10(tm) enterprises and not some piddly organization like yours.

No sir, nobody who is a developer that takes their profession seriously would make a claim that MySQL takes anything seriously. They've cleaned up enough MySQL messes, thank you.

[rant]*one of my biggest pet peeves of MySQL... when I say CREATE TABLE(varchar(255) blah NOT NULL) please do not add your own 'DEFAULT ""' to the end--it is considered by some to be rather rude! I can spot MySQL schema's a mile away by this single trait. Anything NOT NULL almost always has a bullshit default value. Got a NOT NULL int--it will have a DEFAULT 0! Got a NOT NULL date, "DEFAULT 0000-00-00", which isn't even a valid date! How is that for taking your data seriously?[/rant]

Re:Enough already!

[|DeN|niS]

i asked you a valid question, how does innodb not maintain referential integrity? you bring up myisam. i didn't mention myisam. i know myisam isn't ACID. i asked you how innodb isn't. and as for error reporting, http://dev.mysql.com/doc/refman/5.1/en/error-handling.html. so again, how does innodb not take referential integrity and error reporting seriously?

Well, how about completely ignoring the "REFERENCES othertable(othercolumn)" syntax for foreign key constraints without as much as a warning in even the strictest mode, leaving you without referential integrity without any way of knowing?

Or from the manual: "By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes there is a chance that the last statements of the binary log are lost. To prevent this, you can make the binary log be synchronized to disk after every Nth binary log write, with the sync_binlog global variable (1 being the safest value, but also the slowest)."

So InnoDB still defaults to non-ACID behaviour, but it doesn't stop there yet:

More from the manual: Even with [sync_binlog] set to 1, there is still the chance of an inconsistency between the tables content and the binary log content in case of crash. [...] This problem can be solved with the --innodb-safe-binlog option (available starting from MySQL 4.1.3), which adds consistency between the content of InnoDB tables and the binary log. For this option to really bring safety to you, the MySQL server should also be configured to synchronize to disk, at every transaction, the binary log (sync_binlog=1) and (which is true by default) the InnoDB logs.

Another option if you want ACID. Oh wait, there's a 3rd, since binlog defaults to off so you need to enable that too. Three options have to be changed from their defaults to get durability after each and every single commit (when we're talking databases, that's kind of what I expect. If you don't, that's fine, but we're not talking about the same thing then)

, are you referring to companies like google, yahoo, or alcatel-lucent? need i really go on?

Stick to apples-apples comparisons. None of those companies are using MySQL as a relational database (say, doing their accounting in it or trusting their business on it), sure Google uses it as a memory-only non-transactional clustered datastore with an SQL query interface, after having put in a lot of patches to make that work, but so what? Yes, use it for that, sure use MyISAM for your blog, but when we're talking about a proper relational database where "commit" means the data is stored, where a foreign key means a foreign key and where you would run your core business on it then stick to those cases where it's actually used as such. A better example for that is Skype, which runs its entire operations from buddylists to billing on Postgresql.

Re:Enough already!

[mlwmohawk]

Well, we discovered that "elite" is mostly hubris.

I have a problem with the anti-intellectualism in the U.S.A. and it is reflected by this notion that, somehow, elite or an "Elite," is a bad thing.

Everyone has the ability to be elite. It takes time, study, passion, and work. You master a discipline, you attain a substantial amount of knowledge and ability.

Instead of that hard work and ability being recognized, people who do not choose to work, simply dismiss it as "Elitism."

In the software community, software engineers who will debate the finner differences between using "++i;" vs "i++;" stay away from databases and are almost proud of their ignorance.

A good "database," or RDBMS, is an amazing tool. If you are "elite" in your knowledge about data access, storage, and retrieval, you would understand why MySQL is a bad database, however, to understand requires learning more functional computer science. So it is easy for the non-elite programmer to dismiss the whole notion that knowledge has any sort of worth by saying it is simply "elitism" to say that one thing is better than another.

Re:Enough already!

[|DeN|niS]

So you want the column to be NOT NULL, and yet you can't be bothered to tell the db your desired default value for that column. What EXACTLY do you expect the database to do ?

What kind of weird argument is that? Yes I want the column to be not NULL, but why on earth would you just assume that therefore there must be some default value that's acceptable? What if it's also a unique column?

when you say "NOT NULL" as such, PostgreSQL makes it "NOT NULL DEFAULT NULL" which means that yes, it's going to not allow you to INSERT anything that is NULL and you MUST specify some valid value. That certainly does not imply that a sane default exists, and IF it did, I would have just specified it myself in the first place.

Now a "proper" db might just moan at table creation time that you're trying to do something silly, whereas MySQL assumes you are silly and inserts it's own suggested default.

There is nothing silly about having a NOT NULL column with no default (i.e. default is NULL so not allowed). It is a FEATURE of the database to stop me when I have some bug in my code trying to insert a NULL there, just like it is to stop me from inserting a duplicate value, or violate any other constraint I have set.

Inserting its own suggested default is completely braindead, when I say NOT NULL DEFAULT NULL I want the database to enforce that, and to force me to provide proper data. Period. Putting 0 or '' or 0000-00-00 there is retarded, and it's a complete MySQL-ism.

Re:Enough already!

[Dragonslicer]

...or if the application you're dealing with assumes or in some way depends on the case insensitive behavior of MySQL. That alone could make switching pretty rough.

To be fair to MySQL, the case-insensitive behavior is following the SQL standard. Not to say that I like the idea, but it is in the standard.

Re:Enough already!

[totally bogus dude]

(and indeed then have to check that my INSERT actually worked and check for possible returned errors, coding exceptions etc).

So you're one of those "programmers" who doesn't check for errors? So what happens when the disc is full and the insert fails, or someone turned the database server off, or any of the myriad other things that can go wrong goes wrong?

Man, I hate you guys.

-- sincerely, systems admin

My personal favourite at the moment is "retrieving list of products failed: query timed out ... pages of more junk ... crawl succeeded!" Yeah, except the search now returns no results at all. Nice error handling.

Re:Enough already!

[tepples]

When I write NOT NULL in a column, it doesn't necessarily mean I want to enforce that I MUST supply a value during any INSERT (and indeed then have to check that my INSERT actually worked and check for possible returned errors, coding exceptions etc). Therefore I always supply a DEFAULT value, that the DB can safely insert in that column, IF I haven't specified anything different during the INSERT.

Create a table representing customers. I'd specify the column for the customer's name as NOT NULL, so that the database moans when I try to INSERT a row with a NULL name, in the same way that it would moan when I try to INSERT a row that duplicates a PRIMARY KEY. I'd probably even put in a trigger to moan when the app tries to set the column's value to an empty string or any other string without an alphanumeric character. What would you specify as the default value for the customer's name?

Will the real MySQL

[altek]

please stand up?

Re:Will the real MySQL

[Arslan ibn Da'ud]

The real MySQL has learned the first lesson of not being seen: not to stand up.

Re:Will the real MySQL

[VGPowerlord]

Hi, my name is
What, my name is
Who, my name is
My Sequel.

The real MySQL is...

[wandazulu]

...whatever is at www.mysql.com. Look, I'm not trying to be flippant, but when I'm trying to sell the boss on FOSS solutions, I need to send him a link to a site that will give him the warm-fuzzies that demonstrates that a. the tech is solid (typically mention Wikipedia for that one) and b. it's not some fly-by-night operation that will suddenly up and disappear.

I'm not trying to put the other projects down, and I can appreciate why they exist, but this is the exact reason I'm always being laughed out of meetings where they decide to buy an Oracle license, or a Microsoft OS, those guys have the message down (i.e. marketing).

I'm trying to be the in-house cheerleader for what can be done in the free/open-source communities and mixed messages just don't fly to a boss who barely skims the executive summary of whatever glossy lands on his desk any given day.

Re:The real MySQL is...

[digitalunity]

As someone who has extensive hands-on use of Oracle eBusiness, I can say it's a steaming turd with some authority. Having a vertical CRM/order management/invoicing/everything stack is an easy sell to managers, but what they don't realize is it requires significant effort to align it with your business model.

In short, Oracle is designed to sell and it does work, but only well if you're prepared to spend a fortune implementing it.

Re:The real MySQL is...

[Anonymous Coward]

Ah, but those steaming turds are just the ticket for a consultant looking to warm his hands.

I'm a consultant, and I love steaming turds!

Re:The real MySQL is...

[rubycodez]

turds work for the big iron companies too. Like IBM's enterprise solution for anything: sell the client a bunch of overcomplicated rube goldberg contraptions that require a ton of customization and services, big turds for the money sewer.

Re:The real MySQL is...

[Anonymous Coward]

big turds for the money sewer.

And that's why, as a consultant, I'm always "flush" with cash!

Re:The real MySQL is...

[digitalunity]

For starters, the database schema is extremely complicated, much more so than is necessary for most companies. The web interface to eBusiness isn't too bad, although even on big iron it is still pretty slow for a lot of filter and search operations.

The web-launched Java interface takes a LOT of resources per instance; it's very slow on a typical desktop computer. The java interface is MDI, whereas separate windows would be quite a lot easier for users to use. It's also single threaded, meaning one blocking MDI child window blocks the entire eBusiness instance. Clicking the List of Values[...] object is scriptable and in some situations isn't very intuitive. In some cases it will not check the associated field or entered text first, meaning it performs a wildcard search. If done in a field that is populated with hundreds of thousands of records, this can block your eBusiness for 10 or 20 minutes. There is no "break" either, you let it run or you kill it and lose whatever didn't have saved in other MDI children windows.

This is just a short list. There are a lot of reasons Oracle eBusiness is a huge frustration for users and developers.

Re:The real MySQL is...

[the_womble]

a. the tech is solid (typically mention Wikipedia for that one)

So do you edit the Wikipedia page just before you tell your boss look at it?

Re:Ironic

[einhverfr]

Here we have the one shinning open source alternative to commercial databases and it is now faced with an identity crisis because they sold their name to a company about to be bought by IBM and outsourced to China and India.

Huh?

I think the two main open source alternatives to commercial databases are Firebird and PostgreSQL.

Great Sun Acquisition

[gothamboy]

So, then it looks like Sun acquired nothing. The real IP has walked out the door.

Re:Great Sun Acquisition

[greg1104]

There's been plenty of speculation that Sun was interested more in MySQL from the sales side of things than from the technology one. MySQL had figured out how to sell open-source solutions to people for money successfully, something Sun would like to do more of. The high-profile engineers can jump to other projects on a whim, that doesn't necessarily mean they've lost what they wanted out of the purchase.

Database software?

[Anonymous Coward]

What, haven't you people heard of Access??

Re:Database software?

[TheSync]

What, haven't you people heard of Access??

Have you heard of FileMaker Pro??

Re:Database software?

[rattaroaz]

What, haven't you people heard of Access??

No. At my company, we use Excel.

What Sun bought --

[reiisi]

I think what Sun was trying to buy was a little more respect from the open source community.

(At least, that's what I would prefer to think. There is a distinct possibility that that purchase price was heavily subsidized by a certain large company who is quite aware that the best way to kill a technical project is to feed it huge amounts of money.)

Yeah, they went way too far overboard, of course, to actually get that respect.

But, "'e's not dead yet."

Setting aside the brainless rumors of Sun being bought, if I found myself in charge of making the purchase meaningful, I'd be looking at spinning MySQL back out into an independent company and bringing back as many of the guys who built it as they can. Add a couple of developers with other, non-MySQL, database experience to the team, of course, but give control back to the original developers.

Also, don't ask the original developers to give up their independent products.

The MySQL project needed fresh ideas, and this could be one way to bring fresh ideas in. It'd take a long time to get real return on what they invested, but it would be better than blowing away the whole investment.

Anyway, even if the main branch dies, there will likely be some useful development from the forks.

Where is the confusion?

[QuietLagoon]

MySQL resides with Sun. Period. End of discussion.

Re:Where is the confusion?

[sfraggle]

Yeah, the article really answers its own question. Sun own the MySQL trademark, therefore they own "MySQL". There may be other forks, but they are not "MySQL". The end.

*Cough*

[coryking]

I ran into that little nugget when I migrated webapp database from MySQL to PostgreSQL.

As with any webapp, the software would let you create an account on the website. Can't have duplicate users, so the code would check to see if the username existed.

SELECT count(uid) FROM users WHERE username='coryking';

Got "0"? Well, the user is okay... well, at least on MySQL. In MySQL, "coryking", "CorYKING", and "CORYKing" are all the same. As I would soon discover, that assumption is *not* true on PostgreSQL.

Result? A month after the migration, I discovered "unique" accounts for "coryking", "CoryKING" and "CORYKING". Obviously, this can't be. All usernames in webland are case-insensitive. Thankfully, there was only a handfull of these "unique" users to clean up. Had this been left alone for a year, I'd have quite a cleanup on my hands!

Moral? MySQL is case-insensitive, PostgreSQL isn't. Honestly, the proper thing is to be case-sensitive and I assume pretty much every database besides MySQL is case-sensitive. But you have to make your unique index on LOWER(username) instead of username--oh wait, except you can't do that in MySQL cause they dont support indexes on functions... sucks for them!

Good times.

Re:*Cough*

[thzinc]

The real moral of the story is to use the proper collations where necessary. Migrating from a case-insensitive to a case-sensitive collation was the real problem. Also, indexing with the right collation is no problem.

The sociology of MySQL is interesting.

[Futurepower(R)]

"MySQL works OK for one-app databases and many people think that is all that is needed. It breaks down outside that area, however."

You know something is wrong when a discussion of MySQL is dominated by comments about PostgreSQL.

Re:The sociology of MySQL is interesting.

[Skater]

You know something is wrong when a discussion of MySQL is dominated by comments about PostgreSQL.

Or you're on Slashdot. My guess: when the editors see the MySQL article in the queue, they think, "We haven't had a MySQL/PostgreSQL flamewar in a while. Let's post this!"

Re:The sociology of MySQL is interesting.

[h4rm0ny]

It's not that much of a flame war. At the time of posting, most of the comments I see in favour of PostgreSQL are saying that MySQL is fine but for one reason or another they prefer PostgreSQL. And that's actually my position too. I enjoy designing databases and that is true on any system. I've done some of my best work on MySQL - it's fine for me. But for a few reasons (which I wont repeat again), I find PostgreSQL more impressive. Others may prefer MySQL and that's fine. If a preference is based only on the advantages of being familiar with one system, then it's not a valid argument for that system being better, but it's a valid reason for someone to use one of the other. This whole discussion has been shockingly civil for /., actually.

It isn't fud

[coryking]

It is a bit of lore. It is a difference between the two products that you might not have considered before migrating that you better take into account. I didn't even think about it, and I almost got into a huge jam as a result.

SELECT count(uid) FROM users WHERE username=BINARY('coryking');

Except that breaks unicode. Characters aren't byte[]'s, they are characters.

The proper answer is to use the correct collation. The only thing is PostgreSQL doesn't really do that kind of thing yet.

My solution was to create a new datatype based on this example that uses case-insensitive operators. Instead of using the "varchar", I my spiffy new, case-insensitive "ltext" version. Fully indexable too!