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

[digitalunity]

I agree. Use it, live it, love it.

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

[Anonymous Coward]

Yeah, and if PostgreSQL was popular you'd be pimping MySQL.

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

[Anonymous Coward]

Yes, it is. Yes, it does.
More here: http://www.postgresql.org/docs/8.3/interactive/index.html

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]

surely you mean http://www.mysequel.com/

Re:PostgreSQL

[Anonymous Coward]

I don't know why this is marked as Funny...

I'll give you a hint:

there are far too many programs or even webapps (PHP ones in particular) that only work with MySQL.

There's your punchline.

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

[Anonymous Coward]

Not to fond of the lack of type hinting myself - especially of late I've found the planner trips over it's self to get me the longest possible running query. It's frequently quicker to do a more basic query (or pair of more basic queries) and then do the matching in perl or php.

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]

Took me less than 120 seconds to install it with yum then realise config with webmin - went for the word then libs and it was done, then get the idea of how the tables are laid out... thanks for pointing me in this direction.

Admittedly, I have been using MySQL for the past ~ years but I know the power of the extra features and that is what I would rather spend my time learning - for the obvious reasons.

Just a passing observer.

Slanti Mhath.

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

[Thinboy00]

Careful about using the term "Wiki"; a lot of people think "Wiki" == "Wikipedia" || "Wiki" == "Wikipedia article".

Re:PostgreSQL

[Anonymous Coward]

Postgresql didn't accept Feb 30th as a valid date for years....

No decent RDBMS did...

Re:PostgreSQL

[Anonymous Coward]

It's not that they only work with MySQL, it's that they're easier to set up quickly with MySQL.

Postgres is fine if you like that sort of thing. It's kinda/sorta like Oracle, with the same headaches that come with Oracle.

Re:PostgreSQL

[Jack9]

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

Re:PostgreSQL

[Anonymous Coward]

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.

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

[Anonymous Coward]

I have been have the worst issues this week with EDB, I rather deal with mysql.

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

[thatskinnyguy]

I don't miss built-in foreign keys as much as I miss composite keys. I usually enforce quasi-constraints similar to foreign keys in code and it can get annoying at times and I can see where a nice, rigid constraint in the query would come in handy. I see where you're coming from.

Re:PostgreSQL

[rackserverdeals]

Thanks, I just grabbed the fist one from Google that looked familiar. Google must be slipping. :)

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

[Splab]

Well said, I used to laugh when I saw people defend MySQL, these days I get the urge to cry knowing fully well that some day down the line someone will call me up and ask me to help them fix their lost data.

Re:PostgreSQL

[Anonymous Coward]

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

Then why not just the real thing-- OracleXE? It's 10g FREE with some reasonable size limitations.

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

[theillien]

No, it does not support replication and, if the DB I worked with is correct by what he says, it never will. That according to the Postgres developers.

Re:PostgreSQL

[porl]

but all my secret plans are due to be put into action on that date!! how can i use postgresql if i can't store my secret plans in it??

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

[the_womble]

The page linked to does cite a number of sources of information.

Some wikis are actually pretty good - it depends on the community. A lot of IT related wikis are excellent.

I think Wikipedia's variable quality is giving wikis per se a bad name. I have found even Wikipedia to be an excellent source for certain subjects:

1) Anything IT related.
2) Film and TV plots and background info - especially sci-fi.
3) Obscure little towns, especially American.

I wonder why that should be.

Re:PostgreSQL

[Anonymous Coward]

Because sometime's life's too short to waste time getting Oracle set up and running.

Re:PostgreSQL

[andersa]

From a users perspective I found PostgreSQL harder to get started with that MySQL. I use Debian and the MySQL tools are friendlier.

Re:PostgreSQL

[Anonymous Coward]

Who is sometime? Why is his life too short?

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

[dna_(c)(tm)(r)]

It's not FREE, it's free.

And it is crippled (max 4GB)

Re:PostgreSQL

[jridley]

Well then, a lot of people are wrong then. It doesn't mean those of us who know what we're talking about should spend half our time explaining that we're using THIS version of the word or THAT.

I would hope that at LEAST on slashdot you could say "wiki" and have most people realize that wikis were around for a long time before Wikipedia without you having to explain yourself.

Re:PostgreSQL

[jridley]

When the ubiquitous, well-documented and free product has never let you down, how do you define "higher quality"?

For the vast majority of uses, EITHER product will work splendidly. I use MySQL mainly because it was there when I needed a database, already installed, and there were a TON of tutorials and docs online for it. The systems I wrote are running just fine with tables of hundreds of millions of rows, and up to a few thousand transactions a second. We've never had even the most minor of glitches.

Where's the "higher quality" that I'm supposed to be wanting?

Re:PostgreSQL

[Anonymous Coward]

Honestly...this is purely trolling. How it was rated Informative is beyond me.

Re:PostgreSQL

[hlavac]

ACID? Last time I looked, Postgresql was using a flawed "optimistic" isolation model that can work only for read-only transactions, has that been changed?

Re:PostgreSQL

[MinistryOfTruthiness]

...and once you get into the paying versions, you're going to pay dearly. I run my business on Postgres and have been extremely happy with it. I've never lost data, as a development platform it's a joy to work with, and I'll NEVER face a hike in licensing fees. What's not to like? Why "upgrade?" There's very little Oracle or anyone else can offer me that I don't already have with PG.

Someone will come along and say "Well that's good for YOU, but not everyone can do with PG." To that snarky fellow I say, "That's right. It's absolutely perfect for me, and I don't concern myself with everyone else's requirements."

Re:PostgreSQL

[Dragonslicer]

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

Re:PostgreSQL

[Anonymous Coward]

Bullshit. Where I work, I admin both Postgres and Mysql, and Postgres is way easier and faster to install.

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

[Civil_Disobedient]

a product that only supports that db, or developers who aren't particularly familiar with what relational databases are supposed to be like

But then why bother with MySQL at all, when you can get use SQLite? It's fast-as-hell, 99% SQL92-complete, works with application servers (JDBC driver), doesn't require any DB services running in the background, etc.

(For J2EE developers...) You can even hook it up to your app with Hibernate. Excellent not just for small websites, but also good for running "demo apps" with dummy data (since you don't have to install a database server).

Re:PostgreSQL

[Hurricane78]

Do you even realize that real databases have composite constraints, allowing arbitrary constraining and checking of all ingoing data, to a level where the problem of bad input data goes nearly completely away?
That way you can keep your logic layer free from data layer checks.

Re:PostgreSQL

[MinistryOfTruthiness]

Or maybe seasoned programmers understand that they need to use every tool at their disposal to protect the integrity of their data. Maybe seasoned programmers have seen too many cases where a decent constraint on the table would have avoided a LOT of pain when an app bug comes along and inserts a bunch of garbage into a key field.

Maybe seasoned programmers realize that constraints are a form of documentation on the table that is actively enforced by the database engine, so you can be sure when you're kicking off that "delete" statement that the data is as you think it is.

Maybe seasoned programmers have seen too many tables polluted by orphaned records to not realize the value of a delete cascade?

Or maybe belittling as newbs all those professionals who understand the value of these features and the pain that can be caused with out them is a pretty silly way to promote a database that's likely to experience all that pain.

And maybe some time you'll understand that there exists something called "conflict of interest"; but to be fair, it is a shame that a huge piece of MySQL's "yeah but..." argument hinges on the good will of a competitor (Oracle), and that InnoDB development could become unfunded any time Ellison decides MySQL knocked a penny off of Oracle's stock price.

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

[Anonymous Coward]

cause he only has some time to live.

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

[Slashdot Parent]

Does postgres support replication and clustering yet? And please do not include the following words in your reply:
1. "Slony". That is not replication. That is an ugly hack by mis-using triggers.

2. "Pgpool". If I have to lock out all clients just to add a node to the cluster, then it is not a high-availability solution.

Re:PostgreSQL

[quantum bit]

There's very little Oracle or anyone else can offer me that I don't already have with PG.

Basically, built-in multimaster replication (if you pay for the license, of course), and load-balanced clustering. If you don't need either of those, there's really no reason to pick Oracle over PG other than political.

PG is an awesome DB, and it just keeps getting better.

Re:PostgreSQL

[h4rm0ny]

I can't comment on the speed of the two first hand, though I've read very positive things about PostgreSQL's performance against MySQL with the MyISAM and InnoDB table types and especially so with very complex queries. I'm not putting MySQL down - I have extensive experience with it professionally, but for projects where I've had a choice (just home projects) I've gone with PostgreSQL. I can tell you that it is robust, more so than MySQL. And it is powerful. There are a few moments where if you're moving to it from MySQL you'll stop and go "huh?", e.g. good luck setting a column to autoincrement. ;) But don't let anything put you off learning it. It is a great database - very powerful and capabale. If you want shortcuts, look at pgAdmin which provides a nice GUI to it (but learn to do things properly).

I hope that helps. I use both databases and enjoy working with both. But it's PostgreSQL that I am most impressed by.

Re:PostgreSQL

[bytesex]

As much as I like postgres, and use it everywhere; as much as I think mysql is the result of years of a its-not-our-fault, why-dont-you-code-it-in-the-client finger-pointing mentality, this is off-topic. Sorry.

Re:PostgreSQL

[Slashdot Parent]

Is there a decent postgres clustering solution that doesn't force you to lock out all client access when adding a node to the cluster (e.g. pgpool)?

Re:PostgreSQL

[bytesex]

It replicates through slony (through triggers), and it can be replicated using any custom app that reads the WAL-format.

Re:PostgreSQL

[poot_rootbeer]

Hey, maybe people have a reason to use MySQL - a product that only supports that db,

Badly written software.

or developers who aren't particularly familiar with what relational databases are supposed to be like.

Badly written software waiting to happen.

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

[bytesex]

God, I just spent the weekend on-and-off trying to set up joomla using their supposed 'famous five minute setup'. In the end I resorted to editing the configuration.php file by hand and finally succumbing to having it live under the webroot (where I didn't want it to live, but hey - it's php, the last and only thing you'll ever want !). Lots of headaches that are mainly related to php, but mysql was no walk in the park either; is it me, or why is a 'user@%' different from a 'user@localhost' ? That took me a good hour of life that I'll never get back.

Re:PostgreSQL

[Bill, Shooter of Bul]

If anything, google and percona's patches for innodb demonstrate that the community is not dependent upon innobase/oracle to continue developing innodb. There is also the pbxt storage engine which seems to be farther along than falcon.

Re:PostgreSQL

[|DeN|niS]

2. "Pgpool". If I have to lock out all clients just to add a node to the cluster, then it is not a high-availability solution.

As opposed to a database where modifying a table (add/remove an index, column) results in the entire table being rewritten on disk under a full table lock ? And you actually argue that database for high availability ?

As opposed to: The cluster can not be expanded dynamically, and has to be restarted to introduce new nodes. This limits availability in a dynamic setting. (source). Or directly from the horse's mouth: Adding and dropping of data nodes. Online adding or dropping of data nodes is not currently possible. In such cases, the entire cluster must be restarted. ?

Re:PostgreSQL

[h4rm0ny]

For full on survive the Apocalypse functionality, there's Oracle. For everthing else, there's PostgreSQL. The only other downside I see (and it's probably my ignorance rather than a lack of availability) is that I don't know of any large companies that offer good PostgreSQL, whereas Oracle are, well... Oracle.

I stand ready to be corrected, though.

Re:PostgreSQL

[Slashdot Parent]

Pgpool can't even add a node to a degraded cluster without client lockout. This is totally unacceptable.

Regarding mysql, you are right, adding a data node requires a restart, but mysql cluster restarts are "rolling restarts". Clients are NOT locked out during a rolling restart. BTW, even the rolling restart can be avoided if the initial cluster in configured with extra, unused node groups added to the config file for future expansion.

You can find the instructions for the online adding data nodes to a MySQL cluster here.

No DML statements are blocked during the above operation.

Re:PostgreSQL

[mrjohnson]

Ha, no it works great. Actually I've got major financial applications running on Postgres for over 5 years now. The best thing about the concurrency model is no rollback or log or temp space hassles like Oracle or Mysql (similar model) -- everything is done in the table.

My databases get hammered all day long by the user's poorly written Access reports (not my idea, long story) and I never get complaints about speed even when the load average goes over 3 or 4.

I'm not really a database guy, I just play one on TV. For me, Postgres makes it much easier to setup and forget about it.

Re:PostgreSQL

[mrjohnson]

I sold my company on it a few years ago by pointing out a couple companies that had per incident support with no contracts. I told them we could call them up if we had to.

That satisfied their support concerns and when there were never any problems, the question never came up again.

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.

Re:PostgreSQL

[mrjohnson]

My favorite problem with mysql. Awesome.

Re:PostgreSQL

[tweek]

I've implemented to large databases on both MySQL and PostgreSQL (500GB-1TB) and both have ups and downs.

Large datasets is a relative term. My general rule these days is OLTP on pgsql and OLAP on mysql.

Re:PostgreSQL

[krow]

Hi!

The Developer's who are working on the Drizzle's JDBC drivers are licensing these under the BSD license. I am expecting to see this difference go away over the next year or so (and not only for JDBC, but for all drivers). My personal opinion is that developers shouldn't have to get into license debates every time they go to integrate open source code.

Cheers,
      -Brian

Re:PostgreSQL

[tayhimself]

I've come across this several times myself. Its a PITA but you get used to it.

Re:PostgreSQL

[h4rm0ny]

Per-incident support. How I would like per-incident support in other areas! Although perhaps on second thoughts, if this became the general model it would encourage people to submit buggy code to O/S projects, so perhaps it wouldn't be great. :)

Re:PostgreSQL

[jadavis]

Trying to be as objective as possible:

  * The pieces fit together more seamlessly. With MySQL, there are weird exceptions like "you can't use full text search with InnoDB".
  * More developer friendly: many nice, rich data types, offering multiple languages to write functions in, consistent and predictable behavior (few surprises)
  * Very extensible -- if you have an idea, it can probably be done without recompiling or even stopping the server. Even if you don't want to do it yourself, maybe someone else has (cf. PostGIS extension).
  * transactional DDL -- you don't know what you're missing until you have this. You can begin a transaction, rename a table, make a new table in it's place and populate it with data, and commit -- all without taking the application down! And if you have a problem halfway through, just ROLLBACK.
  * I think it's a little more welcoming to developers. You can write a function in perl as a humble user and the statements you issue inside it will follow ACID semantics right along with the rest of the transaction outside the function. Or, if you're superuser, go ahead and open a socket connection and go crazy. PostgreSQL isn't afraid of your code.

However, MySQL is still strong in a couple areas:
  * simple replication
  * in-place upgrades
  * If you really know MySQL well, you can probably avoid many of its pitfalls and make it do what you want. This isn't really a strength, and it's not 100% true, but take this as a mitigating factor to anyone who complains about MySQL.

Re:PostgreSQL

[DiegoBravo]

Yes, yes.... but your database constraints just can access to other data already in the database, not, for example, in the application memory, or a remote system, etc... Of course if all your application is done in stored procedures, your constraints can be more effective.

Now, beyond some arithmetical formulas, constraints are problematic because 1) domain logic code duplication 2) the performance hit.

Of course, constraints are beneficial as any additional check that you can add in your system. But my point is that beyond relational consistence, they can't do much for the correctness of the application data as some DBAs seem to believe.

Re:PostgreSQL

[Simetrical]

http://www.postgresql.org/

Just saying.

So let's restrict our domain a bit for a moment, say to websites. Google uses MySQL for some of their databases. Yahoo! uses MySQL for some of their databases. So do YouTube, Facebook, Wikipedia, and Baidu. That's six of the top ten websites. I couldn't quickly find info on blogger.com or MySpace (too many hits to blogs hosted there!), and presumably live.com and msn.com use MSSQL. That covers all of the Alexa top ten websites. In other words, every top ten website that I was able to find info on uses MySQL, unless it's Microsoft-owned (I didn't even bother checking those).

So tell me: if pgsql is so superior for all purposes, why aren't these places using it instead? Are any of the ten using it at all? What's the biggest website you can find that makes serious use of PostgreSQL? You can't claim that application compatibility or hosting availability are relevant to sites that write their own software and run their own server farms.

I've seen a lot of claims about how much better pgsql is, but somehow big websites aren't using it. Maybe it's more popular in non-web settings? I'm a web developer, so that's what I focus on.

Or maybe, just maybe, pgsql is actually worse than MySQL in some ways that a majority of the top websites have spotted. Just saying.

Re:PostgreSQL

[mlwmohawk]

So tell me: if pgsql is so superior for all purposes, why aren't these places using it instead?

Populous arguments are useless. If Windows is so bad why does it have a lock on the desktop market.

Or maybe, just maybe, pgsql is actually worse than MySQL in some ways that a majority of the top websites have spotted. Just saying.

I have, many times, on Slashdot and at employers made very good cases as to why MySQL should not be used. Here's two:

create index myindex on FOO(BAR)

Which will lock the table until it is rewritten. So, when your site is under heavy load, you CAN'T fix it without killing it.

select * from FOO where BAR = myudf(xyz)

Even if there is an index on FOO(BAR) MySQL is too STUPID to use it, you get a full table scan.

I have a ton of issues I can write about, but suffice to say, the index example is a show stopper for me.

Re:PostgreSQL

[jadavis]

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

The project changed the name to PostgreSQL in 1996:
http://www.postgresql.org/docs/8.3/static/history.html

# MySQL was first released internally on 23 May 1995
# Windows version was released on 8 January 1998 for Windows 95 and NT

-- http://en.wikipedia.org/wiki/MySQL

I doubt that the internally-released version of MySQL on non-windows platforms was so amazingly successful that PostgreSQL felt a need to copy the name.

More likely, it's because PostgreSQL just started supporting SQL, and they wanted the name to appear for anyone searching for a SQL DBMS by typing in "SQL".

Re:PostgreSQL

[jadavis]

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

Just to clarify: InnoDB is GPL.

A fork is still non-trivial business. Trying to do actually accomplish anything requires a lot of organization and talent. And in the interim, you have a problem where there are:
    * multiple forks of MySQL
    * multiple storage engines
    * multiple forks of a single storage engine: InnoDB

That makes QA, support, and usability a nightmare. It would take a very strong leader to really bring it all together into a single product again.

Re:PostgreSQL

[jadavis]

I am pretty sure that that MySQL still has better client slave replication

It depends on what you mean by "better".

Slony-I is a good asynchronous master/slave replication system for PostgreSQL. It takes a lot of effort to administer, but it is also very flexible, and supports some very sophisticated features like:
  * cascading replication (e.g. slave sends data down to other slaves)
  * per-table replication so that some nodes can be master for some tables and others can be master for other tables.
  * can replicate between different versions of PostgreSQL

And the ".ORG" in "slashdot.ORG" uses PostgreSQL, and Slony-I, the last time I checked anyway.

Re:PostgreSQL

[dgallard]

> I doubt that the internally-released version of MySQL on non-windows
> platforms was so amazingly successful that PostgreSQL felt a need to
> copy the name.

I stand corrected (am humbled by the facts, per your sig).

My confusion is partly because I was familiar with Postgres from
the mid-1980s (and with is predecessor Ingres from the early 1980s),
so when it changed names I remember feeling that the venerable
old name had been ruined.

Funny one memory of facts can become corrupted. I should have
checked my facts before spouting off. The rest of my post stands.

Thanks for the history pointers.

Re:PostgreSQL

[Simetrical]

Populous arguments are useless. If Windows is so bad why does it have a lock on the desktop market.

Because of application compatibility and user ignorance. The people who run these sites are not going to have big long-term problems with compatibility (because they write their own apps) and are likely to be very informed. You think Google decides what technologies to use primarily out of inertia instead of technical merit?

I happen to know the DBA for Wikipedia, Domas Mitzuas. He does know about PostgreSQL -- I think he's said he's had patches accepted by them -- and he doesn't believe it would scale to Wikipedia.

I have, many times, on Slashdot and at employers made very good cases as to why MySQL should not be used. Here's two:

create index myindex on FOO(BAR)

Which will lock the table until it is rewritten. So, when your site is under heavy load, you CAN'T fix it without killing it.

Wrong. You can do it, it's just a pain. Any large MySQL site uses replication with multiple slaves. Take a slave out of replication, add the index, add it back to rotation, let it catch up, repeat for all slaves. Promote a new master, take old master out of rotation, do the same. You now have the new index added with zero downtime.

A pain? Sure. A scalability problem? No. Write a script and it can be done with little effort. This is how Wikipedia does all schema changes. You can even add or remove columns this way -- MySQL uses statement-based replication, so an extra column won't affect replication. So you can add the new column with this procedure, populate it and tell the app to start using it, and if necessary remove any old columns once they're unused. I'm curious -- how would this be done in pgsql without downtime?

select * from FOO where BAR = myudf(xyz)

Even if there is an index on FOO(BAR) MySQL is too STUPID to use it, you get a full table scan.

I'm not clear here, is xyz a column or a constant? If it's a constant, just run myudf() in the application, not the database, and it will certainly be fine. That's mainly a stylistic difference. You usually don't use UDFs in MySQL. Again, not a prohibitive problem. You can't expect MySQL to work well if you use it like pgsql, any more than the contrary.

If it's a column, then I can't imagine any database getting it right without an index scan, if the only index you have is on BAR.

I have a ton of issues I can write about, but suffice to say, the index example is a show stopper for me.

It is not prohibitive. It's a pain. MySQL is a pain to use, that I'll happily agree with. It's stupid. You have to tell it what indexes to use half the time, especially in earlier versions, or else it will decide to do things like filesort a million rows instead of reading ten in order directly from the index (I've seen it happen . . .). A lot of things require some extra work. I'm told this is much less true of most other DBMSes.

But it does scale to very large OLTP workloads. Does PostgreSQL? Who uses it for that kind of workload? I can't say, I don't know enough about PostgreSQL. I'd be interested in hearing actual evidence of it handling very large website workloads. (I assume there are other large workloads it can handle fine; I don't know about those, I'm a web developer.)

Re:PostgreSQL

[mlwmohawk]

If it's a constant, just run myudf() in the application, not the database, and it will certainly be fine. That's mainly a stylistic difference. You usually don't use UDFs in MySQL. Again, not a prohibitive problem. You can't expect MySQL to work well if you use it like pgsql, any more than the contrary.

It is statements like this that indicate to me that "MySQL" proponents don't know a thing about databases.

It is so hard to use MySQL because, sure, there may be a way to get something to work, not always, of course, but it isn't what you expect and you are constantly trying to "trick" MySQL into doing what it is that you want, even though the various permutations that you try are all logically similar.

You are working around a poorly designed query planner!!! You don't just shrug that off, its broken. Deal with it.

How about

select * from FOO where BAR in (select bar from froboz where name = xyz);

It won't use an index for BAR!! That is BROKEN. It is indefensible.

Re:PostgreSQL

[Simetrical]

You are working around a poorly designed query planner!!!

Sure we are. No arguments there. But apparently that's not enough of an obstacle to stop people from using it. Even people who have a lot of knowledge and experience. So you can complain that MySQL is a pain to use, and I'll agree with that. But that still doesn't answer my (quite narrow) question: do you, or any other PostgreSQL advocates, have any solid evidence that PostgreSQL will actually work for (e.g.) very large websites? Will it scale as well as MySQL on comparably priced hardware?

How about

select * from FOO where BAR in (select bar from froboz where name = xyz);

It won't use an index for BAR!! That is BROKEN. It is indefensible.

In MySQL 4.0, that doesn't even work. Subqueries aren't supported. You'd rewrite it as a join. Not a big deal:

SELECT foo.* FROM foo JOIN froboz ON (foo.bar = froboz.bar) WHERE froboz.name = froboz.xyz;

You'd prefer to use subqueries? Good for you, then use pgsql. That still doesn't answer my questions, it just restates the point (which I explicitly agree with) that MySQL is stupid and annoying.

Re:PostgreSQL

[stry_cat]

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.

Um... wouldn't that be a reason to use MySQL?

Re:PostgreSQL

[mlwmohawk]

You'd prefer to use subqueries? Good for you, then use pgsql. That still doesn't answer my questions, it just restates the point (which I explicitly agree with) that MySQL is stupid and annoying.

What you dismiss as merely "annoying" astounds me. It is "broken" it does not support SQL in any reasonable way. Consider a C compiler that would have several orders of magnitude difference in the way if processed "*p++=0" vs "*p=0; p++;" IN THE WRONG WAY!

   

Re:PostgreSQL

[Simetrical]

What you dismiss as merely "annoying" astounds me. It is "broken" it does not support SQL in any reasonable way.

I never said otherwise. It still works just fine as a database engine. Possibly even better than PostgreSQL for some things, if the people running the top websites know what they're doing (I hope they do). Databases don't have to fully support SQL to be functional, or even support SQL at all.

Re:PostgreSQL

[wolfie123]

No, not when you are working on commercial, closed-source projects.

Re:PostgreSQL

[krow]

Hi!

When we forked for Drizzle we rewrote all of the client code so that it could go under the BSD. So for Drizzle clients only need to link against libdrizzle.

In the MySQL world? There are several public domain/LGPL/BSD client libraries out there. If you are stuck on the GPL it is just because you have not looked around.

Cheers,
      -Brian

MariaDB link is incorrect

[Matchstick]

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

Re:MariaDB link is incorrect

[Anonymous Coward]

that's fucking funny... don't the slashdot editors read the articles before publishing them? god that's so stupid...

Re:MariaDB link is incorrect

[buchner.johannes]

Sounds like the MySQL devs need a distributed version control system...

Re:MariaDB link is incorrect

[grantek]

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

Re:MariaDB link is incorrect

[joib]

Um, they are using bzr. The official MySQL tree is on launchpad. IIRC Drizzle and Maria are also hosted there.

Re:MariaDB link is incorrect

[sneilan]

Will the real MySQL please stand up, please stand up, please stand up?

Re:MariaDB link is incorrect

[tepples]

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

That's what trademarks were supposed to be.

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?

[digitalunity]

I was under the impression they got the trademark AND the copyrights, meaning they can release a closed source version.

Don't MySQL developers assign their copyrights to Sun?

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?

[Anonymous Coward]

.. uh, yeah. duh. and they make more money than you.

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?

[MrEricSir]

Okay.... what he said.

Anyway, I guess Sun's history is plagued with poor business decisions so this MySQL disaster shouldn't surprise anyone.

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.

Re:Selling an open-source software business?

[Xoth]

No no no you all have it wrong. It was a simple case of ego. The guy with the kimono pissed off the guy with the pony tail, so the guy with the pony tail bought mysql to spite him.

Re:Selling an open-source software business?

[monoqlith]

They bought a brand, something that the non-business open-source community can't build because all-too-often our reaction to disagreements is to fork or start a new project.

Some brands are beginning to exist(Firefox, Ubuntu, to name a couple, but those are sponsored by a Foundation and a private enterprise that need revenues.) I guess it comes down to what our motivations are for writing free/open-source software. If it's not to make money or build brands to compete with proprietary brands, then forking is all fine and good. But if it is to compete with Windows, we could take some cues from the business community and focus on building solid brands rather than forking or starting new projects every time we get frustrated.

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

[Anonymous Coward]

I came here to post nearly the exact same thing.

I'm about as big of a supporter of open-source and both kinds of "free" software as you can get, and I can feel the M$ cronies at my office circling this story already. It's probably Sun's fault this happened, but it will do nothing positive for the open-source/free software community at large.

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.

Re:Not a good precedent

[moderatorrater]

I disagree. Investing in open source is all about time, not money. When you start a business selling support for open source, you expect that the developers you attract won't be in it for the money, although they'll certainly take it. When you buy the company, it's not the traditional acquisition, it's one where you buy the opportunity to take control of a few parts of the project. If you fuck with what the employees love about the project, then they'll leave and either fork or create a new one.

What Sun could have done was buy the company, leave it almost exactly the way it was but to sell support for the entire stack while encouraging the developers to work on Sun-related bugs first. Instead, they tried to fuck with the formula, and the developers left. If Sun's really wanting to, they can bring more developers on that are either in line with the new business decisions or are working for the more traditional reasons. They're not so far gone that it's irrecoverable.

Re:Not a good precedent

[williamhb]

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.

It makes me slightly concerned for the longevity of the open source software business model. In 2004, a fair number of companies felt that open source would be not only socially beneficial but also profitable, and investment in open source rose. More recently, many of the companies that seemed the keenest to move in that direction -- Novell, Sun, MySQL, etc -- have been stumbling badly. Red Hat seems to be left as the sole successful high profile champion of an open source business model. If the result is the business types concluding that open source generally does not allow a viable business model and it is therefore not worth investing in open source development, that could be quite bad news. (Like it or lump it, a lot of open source development is paid for by those business types.)

Re:Not a good precedent

[cdrguru]

I would suggest that if Sun discovers that significant value has left with some people that benefited mightily from the purchase they could be looking at a lawsuit designed to (a) recover whatever portion they received and (b) make sure a solid message is sent to anyone left that leaving isn't an option.

Sure, there are some risks to pursuing a course like that, but we're not talking about chickenfeed here. MySQL wasn't going to earn Sun a billion dollars over the next five years no matter what. But if their purchase has almost no value left, they are going to be looking at it as a really bad transaction. So will all the shareholders. There is also the possibility that a purchasor of Sun could go after the people that left.

Can they do this? Sure, you can sue for any reason. But this has a pretty strong precident with other companies and purchasing stuff that was devalued because of the actions of the founder and/or leaders. Did the people leaving have a contract saying they had to stay? Maybe not, or maybe they stayed for the duration of that contract. Doesn't matter - the point isn't staying but not decreasing the value of the acquisition.

Re:Not a good precedent

[xous]

Not really on topic but shouldn't your signature be:

-1:Troll || -1:Flamebait != -1:StronglyDisagreeAndWishToCensor. Look up the definition of flame/troll.

Re:Not a good precedent

[syousef]

I've gone for the human parse instead of the compiler. Think of it as shorthand, not C code.

Re:Not a good precedent

[Keeper Of Keys]

Red Hat seems to be left as the sole successful high profile champion of an open source business model.

Mozilla?

Re:Not a good precedent

[ivucica]

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

Precisely!

I don't care where the branch came, for I trust in Debian and it's Maintainers. apt-get install mysql-server mysql-client and that's all I care about. Tough for Sun, but that's how it is.

Re:Not a good precedent

[Anonymous Coward]

Mozilla?

There are lingering doubts about their long-term funding, given that Google (who provide most of their funding) now have their own browser.

Re:Not a good precedent

[Anonymous Coward]

How exactly did they "fuck with the formula"?

Most of the things Sun was trying to do seemed reasonable from my perspective.

One example is this MySQL developer complaining about how Sun wanted to scale up so that MySQL can work better across multiple processors/cores.

That seems like a no brainer looking at where everyone is going with multi core, multi threaded cpus. Here's a review of one of Sun's CMT servers that shows a comparison of MySQL vs Postgresql scalability down the page. PostgreSQL blows MySQL away.

For a MySQL developer to be complaining that Sun wants to scale up when that's where everyone is going is ridiculous. You can build yourself an 8 core opteron system pretty cheap these days. 16 cores is even possible but not cheap.

Database do better when they scale vertically rather than horizontally. It's also much easier to maintain. The best price performance you'll get for most db applications is to have a single server with a lot of locally attached 2.5" Velociraptor or SAS 15k Drives.

And for I'd guess 99% of the people posting on here, you could host their sites all on the same box and nobody would tell the difference.

The only other thing I can recall is when MySQL CEO announced a new tool that would be available for Enterprise clients (paid) only but then Sun made them open source it.

Sounds to me like Sun might have been good for MySQL, but I'm not so sure MySQL will be good for Sun.

I think MySQL will start loosing more towards PostgreSQL as people need a better RDBMS and to these newer non RDBMS DBs that are coming out for those that just need an easy scalable persistance layer.

Re:Not a good precedent

[xous]

hehe

*shrugs*

confused me. I guess I spend toooooo much time coding.

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).

Re:Allow to say:

[countach]

If its GPL then even the non-owners of the code have most of the important rights. I suppose they could have asked employees to sign non-compete clauses, but that would seem pretty silly for a GPL product. Besides which, why would employees of MySQL want to agree to what SUN's lawyers want, unless they were getting paid off for it?

Re:Allow to say:

[drolli]

I disagree. You dont hold the right, you were give a license. This is a mile off.

The most interesting thing about having the rights onto a GPL project code is the following:

Most people stick with the mainline, unless they really need the additionl features. The owner of the code can offer "the next" version as closed source first to his customers and earn money on selling the additional features. Sindce the project is GPL anybody can get accustomed to it and every customer knows that if he just wants to mothball a system for archival purposes (never underestimate the need for that in industrial settings), he does not hav to pay license fees to update it, but most likely th normal soon to be GPLed version will be enough. And by this method, the customer drive innovation because they only pay for innovaton; this means your team has clear incentives

Did i mention the great effect of a GPLed product as an advertisement?

So yes, posessing code also licensed by GPL can be a very profitable business model.

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!

[digitalaudiorock]

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.

...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.

Re:Enough already!

[mlwmohawk]

Enough with the knee-jerk elitism.

Gee, I remember a time when "Elite" was considered a good thing by educated people.

If I have open heart surgery, I wan an "Elite" doctor.

If I fly on a plane, I want an elite pilot.

If I setup a database, I want an elite database.

Re:Enough already!

[reiisi]

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

Re:Enough already!

[JPortal]

Elite is different from elitism. They are also usually mutually exclusive.

Re:Enough already!

[Anonymous Coward]

If the host you're using requires MySQL, they probably already provide a version for you. If that's the case, this article really isn't about you -- the problem is handled by your hosting provider.

On the other hand, if you're running a server or using vpslink, you're probably in control of your own database, and can (and should) use postgres.

Re:Enough already!

[Fulcrum of Evil]

And now pretend that you are, like many thousands of other people, hosted in a place that doesn't offer it.

Well, if it's anything big, it's probably a virtual server, so you can install anything you like on it. Event pgsql.

Enough with the knee-jerk elitism.

So wanting a DB that takes things like referential integrity and error reporting seriously is elitist? Bite me.

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!

[Anonymous Coward]

Obviously, the issues you face are more important to you than the ones you don't. But, how could you leave out multi-core scaling? If that isn't the most obvious reason to use postgres ... you don't have much of a database to worry about.

Re:Enough already!

[Anonymous Coward]

I like postgresql a lot and I use it. And while it's a snap to setup, it's not always easy to maintain and make fast. There are a lot of knobs to play with and that may be part of the reason geeks like it.

The project as a whole would be well served by some sort of optimizer for the whole data base configuration itself. Maybe an install wizard like app. Just google, it's like a standard thing for a postgresql user to blog about, optimizing it for speed, there must be hundreds of "howtos" and blogs on it. Once you know it, it's all pretty easy but if you're coming in cold, you have to figure some stuff out. Take socket access, it's off by default from the source and in most Linux distribution installs; that means no jdbc, no mono.net, no ruby or python access, maybe no php too (I thought there was a libpgsql version of a php connector but I don't know.) So you go edit the postgresql.conf file, enable it, then you restart, that breaks because you just made made that file owned by root... it's a fairly silent failure typically. One you're through that you have to add some permissions in pg_hba.conf, it's straight forward enough. At this point you're probably good to go, however your performance settings will absolutely suck; there are just a couple settings you can alter in postgresql.conf (remember to fix the owner) that can radically improve general case performance and make it almost like MySQL out of the box, they almost always need to be set by the end user though. It's fairly simple stuff but it's just extra steps to some hack that just wants to start banging out a web app he's getting paid to design.

Re:Enough already!

[Anonymous Coward]

"it's about using the best tool for the job"

Absolutely. But people still use phrases like "knee-jerk elitism" to slam someone while looking like they're actually slamming their position, and they don't even have to give evidence to support their position! Sweeeet!

I'm a DB nobody who started with mysql. I looked at postgresql and was completely impressed with the quality of the docs (which I needed, let me tell you), but especially with the level of quality of the discourse in the usenet groups. Utterly professional. Open and open to all but completely hard-nosed about the quality of the product.

Both (all) RDBMSs have gotchas, but postgresql wouldn't be caught dead releasing with some of the crap mysql has put out in GAs. The only things mysql has over postgresql is its ubiquity, application lock-in (for those apps that have you locked in) and its speed in simple queries, and even the speed deficit is being lessened with every release, especially since 8.2. For anything more complex than the aforementioned simple queries the choice is easy.

But like you said, it's about the right tool for the job. But the right tool doesn't mean the only tool.

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!

[adamchou]

should use postgres? wow, thats quite a bold statement to make. did everyone who runs a server suddenly learn how to become a dba? if thats the case, i want those powers suddenly infused into my brain too.

Re:Enough already!

[adamchou]

So wanting a DB that takes things like referential integrity and error reporting seriously is elitist?

no, but degrading everyone else that has no interest in using it is. and by the way, how exactly does innodb not take things like referential integrity and error reporting seriously?

Re:Enough already!

[Anonymous Coward]

The ability to select across databases. The ability to select from a variety of DB Engines. There's two reasons I DON'T use PostgreSQL for some things.

Re:Enough already!

[digitalunity]

Anyone who isn't a dba will have their DB dictated by the the software they're using.

Whether or not the db dictates the software or the software dictates the db depends a lot on how important data integrity and the db features are to you. Whether you end up with PostgreSQL or MySQL, you need similar skills to maintain it.

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!

[adamchou]

you might not have been degrading (you kind of are with your last statement), but plenty of postgres, mssql, and oracle users are. i hate going into ##sql on freenode, asking a question about SQL 92 joins and I get kicked because I said I'm using MySQL. WTF does mysql have anything to do with SQL92 syntax?

and here's where you start to get slightly condescending...

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:

and

Or are those examples only good for Fortune 10(tm) enterprises and not some piddly organization like yours.

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?

by the way, when you say

piddly organizations like yours

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

so even though you say you aren't being condescending, you still maintained to act like an elitist pretentious ass. congratulations. thats exactly the type of attitude us mysql users are fed up with from you non-mysql users.

and yes, i agree with you that mysql's not null default data is complete bullshit, but that was never part of your original argument

Re:Enough already!

[the_womble]

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.

Because you can search it much more flexibly than a file system. Suppose Slashdot stored all the users data in a file system, how would you search for my recent posts? How would you would your track friends and foes? You could do it, but the easiest thing is to use and existing DB (either an RDBS or a document DB).

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

MySQL owes much of its popularity its use in CMSs.

Re:Enough already!

[Anonymous Coward]

If only someone had looked at AIG's database!

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!

[daveime]

[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]

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 ?

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.

Horses for courses I would have said. Just for interest, as I'v enever tried Postgre, what does IT do ? Allow you to continue, then moan when you try and do an INSERT, or does it really stop you at creation time with a warning / error. I mean this seriously, I'm interested to know how much better it is than MySQL, but really don't want to install it just for a simple question like this that really would separate "professional" DBs from "amateur" DBs ?

Re:Enough already!

[Anonymous Coward]

Where are these retards who refuse to touch a new piece of software before they've had training, that all these companies seem to keep employing?

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!

[Anonymous Coward]

No, an "elite" is someone who is better than "very deadly". Now get off my lawn.

Re:Enough already!

[daveime]

Yes, yes, I get your point, and we can bandy semantics all day.

In the real world however, people tend to look at columns in a database in the same way as they see a variable in a program. Depending on the language, a declared but undefined variable can be "NULL", or "undefined", or more commonly, defaults to what is considered an "empty" or default value suitable for that column. i.e. strings take on the value "", integers take the value 0, etc etc.

You seem to want to encourage a mindset that separates people who work with DBs and programmers who more often than not, work with these "empty" values in their code, and expect the same behaviour from the DB. Sort of counter intuitive to a lot of us, especially those of us that have to perform BOTH programming AND DBA tasks.

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.

THis also means that I also do not need to code checks everywhere I will subsequently USE that column's data to see if it is still NULL, or if there is something in it. I am guaranteed that even if I haven't explicitly set anything, the column will have taken the default value instead, and CANNOT contain any NULLs.

Sorry if I missed something critical, but it seems like you are trying to put all the load onto the programmer just so you can have a "cleaner" table definition ? Seems a bit counter-productive to me. Especially when you read that table definition, which says somethig like "nulls are not allowed, and the default value is null" ???

Re:Enough already!

[|DeN|niS]

I'm not sure we actually disagree

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. THis also means that I also do not need to code checks everywhere I will subsequently USE that column's data to see if it is still NULL, or if there is something in it. I am guaranteed that even if I haven't explicitly set anything, the column will have taken the default value instead, and CANNOT contain any NULLs.

Certainly. My point is just that this should be the behaviour only when you explicitly define what the default value should be. The database should not make up some default for me. There IS a big difference between '' and NULL, since '' == '' and 0 == 0, but NULL != NULL (actually the result is NULL), which has security implications when you're joining to permissions tables. NULL is a really valuable concept. Phrased differently: if you feel the need for default values or you are not willing to provide a proper value passing all constraints, you probably should not be using NOT NULL but allow NULL and make THAT be your "default", since NULL != NULL and when you don't have a proper value yet, it probably also isn't equal to some other value which you also don't know yet.

In the real world however, people tend to look at columns in a database in the same way as they see a variable in a program. Depending on the language, a declared but undefined variable can be "NULL", or "undefined", or more commonly, defaults to what is considered an "empty" or default value suitable for that column. i.e. strings take on the value "", integers take the value 0, etc etc.

Are 2 strings which are NULL equal? strcmp( some_string, NULL )? Also in C there is a difference between NULL and ''. Again, I would argue to use NULL for when you don't know, rather than some default, again _because_ NULL != NULL

Sorry if I missed something critical, but it seems like you are trying to put all the load onto the programmer just so you can have a "cleaner" table definition ? Seems a bit counter-productive to me. Especially when you read that table definition, which says somethig like "nulls are not allowed, and the default value is null" ???

nulls are not allowed, and the default is null. This is clear, it means it must have some valid entry. I can have a UNIQUE constraint on a colum which allows NULLs, but not on one where the default is '' or such (well I can, but the default can only be used once). I argue against abusing "default values" when it should just be NULL, and against MySQL not honoring that constraint (except in strict mode but than only if it is one row, otherwise it goes ahead and inserts default values into a NOT NULL columns anway?? arghh)

Short version: use NULL when you don't know, not some default value. If I know a person does not have a middle name, then the middle name is ''. This is not the same as saying I don't know his middle name, nor do 2 people of whom I don't know their middle names have the same middle name. I am not saying this is intuitive, but I like my data enough to care.

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!

[schon]

The ability to select across databases. The ability to select from a variety of DB Engines.

In other words "because you don't know what you're doing"?

Re:Enough already!

[Civil_Disobedient]

Do your database wrong, the growth of your company will be hindered. Do it right, and your company will flourish. No joke.

100% truth.

Re:Enough already!

[totally bogus dude]

did everyone who runs a server suddenly learn how to become a dba?

Well anyone who runs a database server is by definition a DBA, just like anyone who drives a car is an automobile pilot. If you don't want to learn what the hell you're doing, then pay someone else to do it for you. You'll only fuck things up otherwise. (Though you probably stand a higher chance of losing data when that happens if you're using MySQL.) Seriously, there's craploads of companies who'll happily run a web and database server for you for a ridiculously low monthly fee.

Doing it yourself has its advantages, but there are some drawbacks too.

Re:Enough already!

[EastCoastSurfer]

If only someone had looked at AIG's database!

Hahaha, the problem is that AIG was most likely using Excel as a database and that is actually a few steps worse than using MySQL as a database.

Re:Enough already!

[TheSunborn]

Quote:
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 ?

I want it to reject the insert(And thus the entire transaction, which btw: is unlike mysql becasue mysql will commit a transaction even if part of that transaction failed, but that's an other wtf).
Imagine that the date field is used to indicate when something is valid(Say, user have paid for access until this date). There is no usefull default and if the application don't give a date then it's a bug in the application and the database should stop that.

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!

[quantum bit]

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 ?

Um, I want it to create the table with a NOT NULL constraint and no default value. That's perfectly legitimate SQL.

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.

No, a proper db will create the table as instructed. There's nothing silly about creating a table that you don't want NULL values in, and saying that there's no sane default, so the user must specify a value on INSERT.

Horses for courses I would have said. Just for interest, as I'v enever tried Postgre, what does IT do ? Allow you to continue, then moan when you try and do an INSERT, or does it really stop you at creation time with a warning / error.

The former (reject INSERTS that don't specify a value for that column), which is what any decent database like Oracle, DB2, and hell probably even Microsoft SQL Server will do.

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?

Re:Enough already!

[adamchou]

(Though you probably stand a higher chance of losing data when that happens if you're using MySQL.)

I see this argument a lot against MySQL... so how exactly do all those people running InnoDB stand a higher chance of losing data?

Re:Enough already!

[tepples]

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

In a comment to a recent Slashdot article about MySQL, someone shared his war story about how MySQL would automatically and silently handle InnoDB tables as if they were MyISAM tables under certain conditions.

Re:Enough already!

[coryking]

What EXACTLY do you expect the database to do ?

Not let me insert NULL values. Not let me forget to put a value in a column when I insert something. I said "NOT NULL" for a reason. I dont want BS values.

I've had this exact argument with somebody before and quite frankly the argument makes no sense. The idea that the database should "do something" all the time is silly, I told it NOT NULL for a damn reason--there should be no default value for a NOT NULL column unless I give it on (like a datestamp on a table). Is NULL a valid username? Is "" a valid username? Nope! If you don't explictly set the "username" on insert or update, then you are trying to corrupt the database and it should stop you. An empty string for a username is an invalid username. In fact, there *is* no logical default value for a username, which is one of the reasons I set that column to NOT NULL!

If you didn't give a proper value or forgot to specify the username, the database should protect itself from corruption. DEFAULT "" is corrupting the database!

does it really stop you at creation time with a warning / error

The only proper thing. You tried to corrupt your database by feeding it trash. A real database would tell you "no way sir, I'm not gonna let you feed me that trash" and throw an error. That's right... invalid data is as bad as corrupt data--in fact, invalid data *is* corrupt data. Who cares about the filesystem corrupting your data when your own table specification corrupts it by feeding it empty strings for usernames and "0000-00-00" as a "default value" when you forget a date.

Re:Enough already!

[coryking]

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.

But that doesn't make any sense. Take this website. Each story has a unique story id--it is a string. It also has to be unique. Tell me a proper default value for the story id? If you think of one, tell me how you will deal with two people editing stories that forgot to add a story id?

Re:Enough already!

[Simmeh]

ah yes, elite was an amazing game. With its own database of worlds ;)

Re:Enough already!

[LurkerXXX]

Certainly, MSSQL and Sybase are sane RDBMS's and will act the same as Oracle and DB2 in that situation. As will Postgresql, Firebird, etc.

I'm not sure if sqlite will, but that's forgivable for a database made to run on PDAs. (not forgivable if people try to use it as a real database on a real computer).

Mysql on the other hand, utter crap.

Re:Enough already!

[coryking]

i asked you a valid question, how does innodb not maintain referential integrity?

As long as you are careful not to mix it with MyISAM I would hope that it does. It is also the only table-type in MySQL that doesn't lock itself on writes.

Honestly though, I'm not sure if I trust the product itself enough to have faith that InnoDB-only transactions would roll back properly. I also am not sure have enough faith to trust it with cascading updates or deletes.

When I have to work on MySQL databases, I only use InnoDB on write-heavy tables where I want a boost of performance and dont need fulltext. It is usually a quick fix to boost performance.

Re:Enough already!

[Anonymous Coward]

I am not a database guy, I'm just trying to follow the arguments and learn something here.

I understand what you are saying about wanting the database to enforce "NOT NULL" when you are trying to write something into the database. You want the database to "stop you".

The concern seems to be what happens when you try to read something from the database. If you specified "NOT NULL" yet have not yet written anything in, will PostgreSQL then "stop you" when you try to read something out?

Re:Enough already!

[Fulcrum of Evil]

i hate going into ##sql on freenode, asking a question about SQL 92 joins and I get kicked because I said I'm using MySQL. WTF does mysql have anything to do with SQL92 syntax?

Good question. WTF does MYSQL have to do with sql? :)

i asked you a valid question, how does innodb not maintain referential integrity?

Simple: forget to use innodb or need FT indexing and all your foreign keys get ignored. IGNORED, not errored out.

thats exactly the type of attitude us mysql users are fed up with from you non-mysql users.

Too bad. Mysql shits itself enough that the rep is deserved.

and yes, i agree with you that mysql's not null default data is complete bullshit, but that was never part of your original argument

Sure it is - Mysql is a joke, and this is just a reflection of their attitude.

Re:Enough already!

[coryking]

Well, NOT NULL is only for writing. If you've got this:

CREATE TABLE blah (
blah_id SERIAL PRIMARY KEY,
username varchar(255) NOT NULL,
favorite_food text
)

(SERIAL = int auto_increment in mysql, primary key = duh)

You cannot do this:
INSERT INTO blah VALUES(favorite_food) ("plain yogurt");

Why? you forgot the username!

But there is nothing wrong with this:

SELECT blah_id,favorite_food FROM blah WHERE username IS NULL;

It wouldn't return anything of course--as there is no username that is NULL.

If your table was this:

CREATE TABLE blah (
blah_id SERIAL PRIMARY KEY,
username varchar(255),
favorite_food text
)

Now you can do that insert statement and the "SELECT blah_id FROM blah WHERE username IS NULL" would start to return stuff.

Re:Enough already!

[adamchou]

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?

This is new to me. I've used foreign keys and seen it complain when the constraints aren't met. I know this happens in MyISAM though (because there are no foreign keys). I'd like to see an example of where InnoDB doesn't respect the constraints

and those other 3 things you said.

1. of course it takes some tweaking of a database to get stuff working the way you want it. granted tweaking for ACID compliance isn't ideal
2. I'm not going to bother responding to each of your points as you know damn well that you were quoting the MySQL 4.1 manual and at least 1, if not more, of your points are invalid now in MySQL 5.0
3. InnoDB defaults to off too. If you're going to enable InnoDB because you're looking for an ACID RDBMS, then you should also configure your database server to properly utilize InnoDB.

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)

Google is using it to power their adwords. How is that not "their business"? besides that, there are plenty of companies out there that run their "business" on mysql. you know it, i know it, every postgres, oracle, mssql dba knows it. here's some more info...

Re:Enough already!

[Anonymous Coward]

Some of those people who think they're running InnoDB actually aren't. Last I heard any server without InnoDB enabled falls back on MyISAM without giving an error, and it's not even possible to disable to MyISAM driver to ensure this never happens. And woe unto you if you miss upgrading any existing tables, because then some of your updates will rollback and some won't!

Re:Enough already!

[Anonymous Coward]

These are really lame complaints. You're upset that InnoDB gives you options for tuning the balance of risk vs. performance? You might better ask why Postgres can't offer some ability to improve speed for applications that can tolerate losing 1 second of data if there's a hard system crash.

And you consider failing to give a syntax error on one unsupported REFERENCES syntax a serious enough problem to use a different database? You're really reaching for these.

Re:Enough already!

[|DeN|niS]

This is new to me. I've used foreign keys and seen it complain when the constraints aren't met. I know this happens in MyISAM though (because there are no foreign keys). I'd like to see an example of where InnoDB doesn't respect the constraints

You can just check the manual, or the bugreports

mysql> create table a ( aval integer not null ) type=innodb;
Query OK, 0 rows affected, 1 warning (0.08 sec)

mysql> create table b ( aval integer not null references a(aval) ) type=innodb;
Query OK, 0 rows affected, 1 warning (0.08 sec)

mysql> insert into b values (10);
Query OK, 1 row affected (0.05 sec)

mysql> select * from a;
Empty set (0.00 sec)

mysql> select * from b;
+------+
| aval |
+------+
| 10 |
+------+
1 row in set (0.00 sec)

InnoDB defaults to off too. If you're going to enable InnoDB because you're looking for an ACID RDBMS, then you should also configure your database server to properly utilize InnoDB.

This is valid, however who actually knows to do that?

Google is using it to power their adwords. How is that not "their business"? besides that, there are plenty of companies out there that run their "business" on mysql. you know it, i know it, every postgres, oracle, mssql dba knows it. here's some more info...

Ok, it is their business, but it is still a memory only non transactional clustered datastore with an SQL frontend. If you're (general you) going to point out examples of why to choose MySQL, point out those cases where it is actually used in the way you want to use your database. Yes, it's plenty good for plenty of companies, but we're talking about an RDBMS in that traditional old fashioned financial reliability sense.

Re:Enough already!

[|DeN|niS]

These are really lame complaints. You're upset that InnoDB gives you options for tuning the balance of risk vs. performance? You might better ask why Postgres can't offer some ability to improve speed for applications that can tolerate losing 1 second of data if there's a hard system crash.

It does, asynchronous commit. Except without corrupting your database if it does happen to crash in between.

And you consider failing to give a syntax error on one unsupported REFERENCES syntax a serious enough problem to use a different database? You're really reaching for these.

If it is not going to enforce the constraint, then it shouldn't pretend to and surprise me later. It's not the only issue, but it's a typical one.

Re:Enough already!

[|DeN|niS]

And you consider failing to give a syntax error on one unsupported REFERENCES syntax a serious enough problem to use a different database? You're really reaching for these.

To give you a fair response, even though you post anonymously, no it's not a good enough reason to use a different database. You can remember to use the "working" syntax. It was a response to a question of why strict mode + innodb still does not solve all the famous "gotchas". A better reason to use a different database, would be to use one with transactional DDL, where altering a table (add an index? drop one?) does not rewrite the entire table on disk with a full table lock. I've mentioned this earlier, so you're probably just trolling.

Re:Enough already!

[quantaman]

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.

That's fine if you like those defaults but you are the minority. Generally if you don't want to allow a NULL value that means that the value needs to be set, not that there's some safe arbitrary default that the programmer didn't even explicitly set.

Sorry if I missed something critical, but it seems like you are trying to put all the load onto the programmer just so you can have a "cleaner" table definition ? Seems a bit counter-productive to me. Especially when you read that table definition, which says somethig like "nulls are not allowed, and the default value is null" ???

This creates a cleaner data definition and helps the programmer. NOT NULL is a godsend, I grab my data and can know that foo.bar is a actual valid number, and when I screw up an insert it tells me right away, not at some point in the future when I'm wondering "Huh? Did I set that to 0 or did the DB??".

Honestly I feel mysql suffers from an extreme case of what ails some of the scripting languages. I suspect that mysql chose this behavior because it results in faster initial code and fewer initial developer frustrations. Basically it allows you to write some sloppy code without the DB yelling that you left X null or violated some constraint.

The problem is that programming needs strong rigorous logic, short cuts come back to bite you almost every time. NOT NULL DEFAULT NULL isn't for the benefit of the DBA, it's for the benefit of you the developer, it gives you that indication that says "Hey! Somethings not right here!" before it develops into a more subtle bug.

Re:Enough already!

[einhverfr]

Ok, but I wasn't thinking of a file system.

Imagine if Slashdot stored all user information in OpenLDAP, for example. Or BDB.

The big difference has to do with flexibility of reporting, not searches, but also I think about buzzword-compliance ("We need an RDBMS because their are COOL even if we are using it like an OODBMS").

Re:Enough already!

[nandix]

All of this is handled properly since v5.0
However, for backwards compatibility, the default mode is that of older MySQL versions, and hence you get default values for invalid data when constraints aren't met.

However, these don't go silently. It's true that an error isn't thrown, but warnings are generated every time a column is truncated or set to it's default data type.

If you want an error while inserting null into a not null column, or while inserting an out of range value, setting sql_mode into something like 'STRICT_TRANS_TABLES' or 'TRADITIONAL' will make MySQL work the way you expect.

It's true that combining MyISAM and Innodb tables in transactional statements will screw up your data, but that's only because you shouldn't be using MyISAM tables in transactions in the first place! If you want transactions, use InnoDB, or BDB, if you need something else. InnoDB is good for 99.9% of the cases in which transactions are needed for MySQL. Complaining that your referential constraints and transactions aren't respected while MyISAM tables are involved is like, I don't know, trying to write data to a closed socket and then complaining that it blows up in your face :)

All of this is properly documented in the manual. As any complex piece of engineering, one shouldn't try to do anything big with MySQL without reading the corresponding manual sections first, or unexpected behavior will arise, and frustration/anger is sure to follow :)

I wouldn't blame postgresql for any bad performance I may get out of it, I would blame my lack of knowledge, since I know next to nothing about it.

Finally, I believe this 'war' thing is just among people who don't really contribute much to either project. The Percona conference is coming by the end of april, and some PostgreSQL folks are giving talks there too, so I'm confident that the hacker community is well above any occasional flamewar :)

Re:Enough already!

[Anonymous Coward]

DB2?

Re:Enough already!

[Anonymous Coward]

Right on, commander!

Re:Enough already!

[rackserverdeals]

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.

There are no finer differences between i++ and ++i, there are functional differences.

i++ is equivalent to:
var v = something + i;
i = i+1;

++i is equivalent to:
i = i+1;
var v = something + 1;

Re:Enough already!

[h4rm0ny]

Or maybe they were using Access, which is a few steps worse than using Excel as a database. ;)

Re:Enough already!

[ckaminski]

I think his whole point is:

If MySQL added InnoDB to *be* ACID compliant (which as a casual MySQL user I assume they did), then it should DEFAULT to ACID (and I have no idea if this is or is not true). I think I'm just trying to make the GPP's post clearer.

From what he's said, in 4.1 at least, the default ACID compliant engine in MySQL is NOT, by default.

Re:Enough already!

[Fulcrum of Evil]

Man, I hate you guys.

Me too - I'm stuck with some nasty slow big-architecture code that I can't fix (not allowed). The devs who wrote it all quit or were canned, but they still think they've got a good or at least workable solution.

Re:Enough already!

[Fulcrum of Evil]

I don't think that sane really belongs in the same sentence with a RDBMS - they all suffer from their own dementia. Difference is, Mysql is mad King Ludwig.

Re:Enough already!

[ckaminski]

They're not saying that at all. They are saying that when they ABSOLUTELY want for there to be a NOT NULL and also valid value, that the database enforce that.

NOT NULL DEFAULT '' and
NOT NULL DEFAULT NULL

Are two separate and different beasts. Both are valid for different use cases, but if I *WANT* the semantics of the second, then the first fails to implement them.

Re:Enough already!

[ckaminski]

No, and why would it? It tells me it's NULL.

This is semantically different from '' or 0 or 0000-00-00 or 000-00-0000

Using the SSN example, from a customer table, a NULL entry tells me that the user might not be an American, which is valid, but not necessarily valid. A 000-00-0000 might only tell me that the user managed to trick my web entry form to enter and invalid SSN. It's splitting hairs in this example, but that doesn't eliminate it's value.

Re:Enough already!

[cbciv]

>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.

That's lovely, but it's not a solution that covers all cases and I damned well don't want the RDBMS assuming that it does. As others have pointed out, there are cases where one might require a NOT NULL column with no default value. If I want a column to have a default value, I'll supply one. If I don't, it shouldn't go behind my back and add one like some sort of damned MS autocorrection feature.

Re:Enough already!

[EastCoastSurfer]

ARRG! The nightmares you just invoked from a job I had while in college. The company I worked for had written a multi-user system in Access (at the time I didn't know any better lol), but access ('95 I think) wasn't really capable of being multi-user. Many a late nights were spent at client sites cleaning up the mess that ensued.

To this day I refuse to use Access in any way, shape or form.

Re:Enough already!

[Anonymous Coward]

like, I don't know, trying to write data to a closed socket and then complaining that it blows up in your face

If I do that, I didn't mean to, so I want it to blow up in my face. If the socket just quietly discarded all my writes and pretended everything was fine, I'd be appalled. Yet people put up with MySQL doing the same thing.

Warnings are not a substitute. Most developers don't even know warnings are accessible from code, much less how to get them. And say you get a warning. How do you recover? The database has already done something unintended and stupid to your data! You don't even know whether or not rollback is actually going to work or just be ignored (or worse, half-ignored) because some forgotten slave server has a MyISAM replica.

Re:Enough already!

[reiisi]

I think you wanted to say,

var v = i++;

and

var v = ++i;

Otherwise, yeah.

Re:Enough already!

[h4rm0ny]

You're not alone. Many of us have such traumatic experiences. We should form a support group. But the concern isn't what's been, it's what is. I knew someone doing their teacher training in the UK two years ago. As part of their mandatory IT qualification, they had to learn to create and use Access databases. The only thing worse than the fact they were teaching Access, was how they taught it. Nothing at all about database theory - just drag this box here, create a form there. And even that they did by hurried rote without explanation or depth. I suspect there's a whole new generation out there waiting to be mentally scarred as we have been.

Re:Enough already!

[rackserverdeals]

Just looked it over. There was a typo but the last line should be:

var v = something + 1;

Re:Enough already!

[rackserverdeals]

Ugh... I mean:

var v = something + i;

Re:Enough already!

[Fulcrum of Evil]

However, for backwards compatibility, the default mode is that of older MySQL versions, and hence you get default values for invalid data when constraints aren't met.

Tell you what, I'll just use a DB that prioritizes data integrity above backward compatibility. Jesus Christ, what drooling moron decided that inserting null into a not null column should result in a default value?

As any complex piece of engineering, one shouldn't try to do anything big with MySQL without reading the corresponding manual sections first

Any worthwhile product should adhere to the principle of least surprise - if you put on airs at being a RDBMS, then you had best behave like one. Stick a compat option for the people who want the bad old way and default to being a proper DB.

It's true that combining MyISAM and Innodb tables in transactional statements will screw up your data, but that's only because you shouldn't be using MyISAM tables in transactions in the first place!

Silly me, not knowing the secret nonportable tweaks I need to add to my sql to make things like foreign keys work.

Re:Enough already!

[einhverfr]

I used to provide tech support for MS Access at Microsoft. I could tell you horror stories....

Will the real MySQL

[altek]

please stand up?

Re:Will the real MySQL

[Red Flayer]

Cuz I'm the real postgre, yes I'm the real postgre
All you other DBs are not relational-y
So won't the real postgre please stand up,
Please stand up, please stand up?

Somehow postgreSQL flows much more lyrically than MySQL.

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

[Anonymous Coward]

I'm Sparticus!... er... nevermind.

Re:Will the real MySQL

[VGPowerlord]

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

Re:Will the real MySQL

[daveime]

Unfortunately, it has chosen a rather obvious piece of cover ..... boom !!!

Re:Will the real MySQL

[Anonymous Coward]

Please don't tell me you actually say "sequel" in public.

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...

[MobyDisk]

I would not recommend trying to sell your boss on a FOSS solution that was bought out by a commercial company who is running it into the ground. There's other projects out there (Ex: PostgreSQL) that are better sells.

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...

[mcrbids]

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).

You are being laughed out of meetings? Sounds to me like YOU need marketing experience, as well. How are you presenting your OSS solutions? More importantly, if you are in an environment where you are laughed out of meetings, WHY are you presenting your OSS solutions?

I present and offer OSS-based solutions regularly. My solutions work fantastically well, have a long-proven track record, and are taken seriously at every presentation, with excellent take-up.

I suspect that you aren't being laughed out of meetings - few people are dumb enough to do that more than once or twice. I suspect, instead, that you are either an astroturfer, or just somebody who likes to grandstand stuff without really understanding it.

Methinks you need to reconsider your strategies. (or STFU)

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...

[Anonymous Coward]

He probably has a real job, implementing ERP systems, whereas you... what do you do, exactly? Low traffic web sites?

Re:The real MySQL is...

[raftpeople]

As someone who has extensive hands-on use of Oracle eBusiness, I can say it's a steaming turd with some authority

Curious if you have specifics. I've worked both ends of the spectrum (completely integrated and best of breed for all apps with interfaces), I definately prefer the integrated approach. What you gain with best of breed you quickly lose in complexity of interfaces, loss of functionality because data from one app's model can't be easily represented in the other app's model and loss of a comprehensive view across all aspects of the business.

Re:The real MySQL is...

[Anonymous Coward]

Funny, thats the exact opposite of what I experience. The marketing material that sun,ibm, microsoft put out persuade our company NOT to buy their crap. Percona especially gets it. Their blog demonstrates their in depth knowledge of both the current problems in the transactional database market, and the best solutions to the common problems. They have cred up the wazzo. If your company chooses its software on the glossiness of the package ... well, your company sucks at making important decisions. Maybe their good at other aspects of their buisness

Re:The real MySQL is...

[Saija]

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.

Ohh my god i never think someone else would suffer the same i suffer in my last job, i saw everything you said plus some manufacturing and planning modules of the eBussiness Suite being hammered to fit the bussiness model of the company, ohh the horror, the horror!.

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:The real MySQL is...

[Keeper Of Keys]

This particular piece of news doesn't look too good on MySQL, but the GP has it right: MySQL is a brand. This is (unfortunately) important. It's on practically every hosted server, people have heard of it and trust it. I've read the arguments that PostgreSQL is superior, but if you're trying to sell FOSS to someone, it really helps if they've heard of the product. (As a web dev, I have a similar problem trying to sell Django to clients who think they want asp.net.)

Re:The real MySQL is...

[Keeper Of Keys]

I like your thinking.

Re:The real MySQL is...

[jalefkowit]

Yes, but part of the point of the article is that the brand is under threat. "MySQL" as a brand relies on the word meaning the same thing everywhere you go -- in much the same way that anywhere in the world "McDonald's" means you can get a cheeseburger. Maybe not the world's best cheeseburger, but you know exactly what to expect when you walk through the doors.

The value of the brand is in its promise of consistency. But if "MySQL" fragments into a bunch of different projects with only a tenuous connection to each other -- Sun MySQL, Drizzle, Maria, Percona, etc. -- then the promise is broken. Webhost #1 tells you they have "MySQL" but it's not the same "MySQL" as Webhost #2 has. "MySQL" consultant A won't work with your database, where "MySQL" consultant B will. Result: confusion and brand damage. And all those people who were attracted to MySQL because of the strength of its brand start looking for alternatives.

This is why the question of "which is the REAL MySQL?" is so important -- if a clear answer doesn't emerge, MySQL-as-brand is in big, big trouble.

Re:The real MySQL is...

[Keeper Of Keys]

But the forks aren't allowed to call their product 'MySQL'. So pointy-haired bosses won't be any more confused by (or even aware of) these other products, than they are of, say Firefox derivatives like Flock and Camino.

Re:The real MySQL is...

[jalefkowit]

You can bet there's going to be lots of people running around saying "Oh, that MySQL isn't the REAL MySQL. [Monty|Drizzle|Percona|etc]'s MySQL is the real MySQL, even if it isn't CALLED MySQL."

Re:The real MySQL is...

[Anonymous Coward]

"The marketing material that sun,ibm, microsoft put out persuade our company NOT to buy their crap"
"Their blog demonstrates their in depth knowledge of both the current problems in the transactional database market, and the best solutions to the common problems"
"They have cred up the wazzo"

How about instead of you fanatics trying to prop up OSS with statements like "My company does/does not use XXX software", you justify that with the size of your company. "Their blog demonstrates" really gives it away, but come on, be honest with us. Please do the same for any "The OSS solutions I recommend for my clients..." crap. A company that hires a contractor to implement a OSS solution... well, that sort of gives it away too, but still, be honest.

Re:The real MySQL is...

[stiller]

Finally, somebody with a grasp on reality. Fact of the matter is, nobody outside of the /. crowd gives a crap about which/what/where codebase. If you own IP, sales, support, you own the product. Forks to them are nothing more than unpaid R&D/market research.

mysql.com

[msobkow]

The pages that come up for "mysql.com" are what I consider to be the "official" version of MySQL.

I didn't even realize the other pages were out there until this article was posted and I started reading the comments.

Not that it matters much -- I'm an http://www.postgresql.org/ fan myself.

Let's start with the Real Official MySQL

[ronaldbradford]

Don't forget even MySQL has an identity crisis on *offical* versions. I wrote about this "Understanding the various MySQL Products & Variants" at http://ronaldbradford.com/blog/understanding-the-various-mysql-products-variants-2009-03-13/

Damn

[Kell Bengal]

The moment I saw the headline, I immediately thought of three smart-ass tags... then I looked down and all three were taken. At least I can still tag it something obvious like 'story'

Ironic

[Anonymous Coward]

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.

So much for that open source licenses if the many people who worked and contributed all of their time to make MYSQL to make it an enterprise level application get shafted by the few.

We've seen many terrible forks in the past but this has to take the cake and usually thatâ(TM)s the last you hear of them we all know how well SUN maintains and contributes to there open source projects as it is. It's been awhile but the last time i checked their STL library it was horribly behind. Now imagine IBM.

Time for postgress, besides it has much better GIS support.

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.

Re:Ironic

[Anonymous Coward]

Yes but MYSQL was the only one that was just starting to be capable of running on large clusters using much more complex storage/data integrity/etc.

Sure the skills required to maintain it are way higher than most dba's are capable (unless your google) but it is possible and i don't see Oracle going anywhere.

We wouldn't want to leave the entire market to MSSQL now would we?

Unless the fork becomes stronger than the name I have really bad feelings about the future of "MySQL" under SUN/IBM.

Re:Ironic

[Anonymous Coward]

Here we have the one shinning open source alternative to commercial databases

Bart: Don't you mean shining?

Willie: Shh! You wanna get sued?

Re:Ironic

[einhverfr]

Yes but MYSQL was the only one that was just starting to be capable of running on large clusters using much more complex storage/data integrity/etc.

You are right that MySQL is the only one that is just starting to be capable of complex data integrity. The others have been there for som etime. For complex storage, etc. yes all three are feasible in complex storage environments, though neither of them are feasible in the sort of DLC environments that Oracle RAC uses, etc.

Re:Ironic

[Unordained]

Firebird arguably has some branching issues (Interbase, Firebird, Fyracle, and Yaffil, at least) but it's not that bad -- Yaffil and Firebird are re-merging, after having explored different problem spaces and come up with different features, they decided it'd be even better to share the new code. I was pleased, for example, when Yaffil's function/expression-based indexing got merged back into the main tree. It wasn't about egos or brands, it was just about features.

Re:Ironic

[Leafheart]

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

not by volume

Re:Ironic

[einhverfr]

Umm..... Only if you include the lowest end.

In which case, I would agree that you are right. MySQL is an alternative to db's like MS Access..... Anything beyond what you SHOULD use Access for complexity-wise you can't use MySQL for either because you can run into many of the same basic problems. This means MySQL is really great at some things (like lightweight CMS stuff, maybe also one-off line of business tools) but these aren't really where the commercial RDBMS market really is. In those cases, usually you have a single db with many, many applications accessing the same data. Even the most recent versions of MySQL make this impossible in terms of validating data integrity as well as an RDBMS should.

Which brings me back to the idea that MySQL is OK for single-app db's. It is totally inadequate for multi-app db's.

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.

Re:Great Sun Acquisition

[gothamboy]

...and they had to spend a BILLION dollars for this education?? ;-)

Re:Great Sun Acquisition

[shutdown -p now]

It would seem that they've just bought the MySQL trademark. I would think that, at 1B, that's not exactly cheap.

Re:Great Sun Acquisition

[Anonymous Coward]

If they make an extra $2 billion sales, then it's worth every cent.

Re:Great Sun Acquisition

[ivan256]

Speculation, sure, but in true "company bought by Sun" fashion they fucked that up too.

Our first renewal cycle after the transaction, Sun tried to triple the price of our JDBC connector redistribution licenses. Non-negotiable.

So we switched to a different solution.

I'll gona try postgresql

[sanotto]

Just because a big gray elephant is easier to find, that some stealth dolphin...

Database software?

[Anonymous Coward]

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

Re:Database software?

[againjj]

Access to what? Above they talked about the difference in access to MySQL and access to PostgreSQL....

Re:Database software?

[Anonymous Coward]

Access, the only database worse than mysql.

Re:Database software?

[TheSync]

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

Have you heard of FileMaker Pro??

Re:Database software?

[Anonymous Coward]

Clearly they haven't

Re:Database software?

[Anonymous Coward]

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

COBOL on flat files, sonny, that's where it's at! You'll never be out of work with them!

(Scarily, that's as near as I can remember to a quote from my 3rd year Databases & Business lecturer, in the late 80's. He refused to teach the SQL part of the syllabus because it was never going to catch on outside academia...)

Re:Database software?

[rattaroaz]

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

No. At my company, we use Excel.

Re:Database software?

[Anonymous Coward]

Worse how? I honestly don't remember Access ever accepting malformed values and silently discarding them and storing arbitrary replacements, or just plain ignoring constraints it didn't feel like enforcing. Getting wrong answers faster is not an improvement.

Re:Database software?

[daveime]

Base ? the only database so bad, that they don't even like to include it in their openoffice installer ?

Re:Database software?

[daveime]

Just wait until the power goes down, and when it comes back up, you go to open the *.MDB, you get the deadly "This is not a valid database - do you wish to convert it to Offcie 97 format ?".

Ciao ciao mission critical data.

Re:Database software?

[againjj]

Wooosh!

Re:Database software?

[ckaminski]

Sadly enough, I managed to go my entire career without ever dealing with COBOL (and I worked in some funky places)...

Well, my current job just dropped me straight into Cobol integration messiness.

Who knew!?

lolcating the real mysql

[Anonymous Coward]

Is it just me, or did anyone read the title as "LOLCATTING the real mysql"?

Which reminds me, I need coffee.

Re:lolcating the real mysql

[geminidomino]

I can has referential integrity?

Its incredibly frustrating

[Anonymous Coward]

To find out for example that when you download MySQL you are not getting the "official" INNODB engine either which yuo have to build yourself on solaris.

I think the distro is becoming somewhat of a cruel joke on users.

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.

Re:What Sun bought --

[raftpeople]

Setting aside the brainless rumors of Sun being bought
Why would you call them brainless, do you honestly think there is nothing to them?

Re:What Sun bought --

[astinus]

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

Well, /. is about as good a hotbed of OSS nerds, devs, and evangelists as you'll ever find. How about it, then? Did they succeed?

Anyone here have more respect for Sun now that they own the MySQL brand?

Lively discussion

[CaptTofu]

I could use some Yerba Mate. Writing books is exhausting, and I will soon be done. I will be able to sleep. Hooray!

I'm glad to have triggered some discussion here. I just want to improve MySQL, that's all.

Enterprise DB

[msobkow]

There are a lot of "Oracle required" situations that can be serviced by http://www.enterprisedb.com/

They provide an implementation of PL/SQL for PostgreSQL with commercial support.

Re:Enterprise DB

[raftpeople]

The parent post was referring to Oracle applications, the ERP software they sell that competes with SAP, not the database.

Re:Enterprise DB

[digitalunity]

Yes, I was. eBusiness is more than just ERP, it's got CRM, order management, invoicing, inventory management, assets, HR, etc, just like SAP.

Don't forget the COPYRIGHT!

[Ungrounded Lightning]

Oh, yes. The Copyright!

With that, Sun can:
  - License the code (non-exclusively) to customers under OTHER licenses than the open source license under which it was released.
  - Sue others for infringement when THEY use it in ways not included in the open source license.
  - Make derived works that they don't release under the open source license.

These are all things that Sun can now do and no others can (presuming Sun continues MySQL's tradition of keeping the main codebase clean of outside code for which they don't have additional non-open-source licensing).

I for one...

[actionbastard]

Am not ready to entrust my data to a talking, masked, styrofoam cup!

Re:Too specific, too narrow

[F452]

It seems to me this is squarely in slashdot's sweet spot.

If the blurb doesn't interest you, give the story and the discussion a pass. There'll be another story soon enough that doesn't meet your specifications either.

Re:Too specific, too narrow

[robbak]

You think that the machinations of what is either the number 1 or number 2 name in the open source world is of narrow interest?
If an executive knows the name of any Open source project, it will be either Linux, MySQL, Openoffice or apache.
Now, while I think that MySQL fading away, and leaving PostgreSQL as the leading database would be a Good Thing, MySQL is still of great importance, and it's fracturing under Sun's (Mis)Management is one of the most important things happening in IT right now.

Found it

[Anonymous Coward]

mysql.com

Get with the new age, people

[Anonymous Coward]

What tree is the official MySQL tree is irrelevent. What is important is that Monty got his billion.

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.

Whatever Google Says

[NotQuiteReal]

At the moment, the top listing is www.mysql.com - Duh.

started my own engine - firebird

[mAriuZ]

I'm already sick of innodb and myisam issues also falcon and maria are in alpha/pre alpha stages
maybe it's easier to write an new engine for an stable db like firebird/postgresql
I will post my progress on this page
http://mapopa.blogspot.com/search?q=mysql

ahh by the way firebird engine is stable for more that 20 years (triggers/transactions are normal things from that time)

http://www.firebirdsql.org/index.php?op=history&id=beginning

*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*

[binary paladin]

I had a similar experience, only with sqlite. Weird. I'd come from a MySQL/MSSQL background and was used to things being case insensitive.

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.

Re:*Cough*

[Jacques Chester]

Was there a reason you didn't just mark the username field as unique in the schema SQL? I can't think of one off the top of my head.

Re:*Cough*

[coryking]

The real moral of the story is to use the proper collations where necessary

Indeed. However, at least when I had the problem, there was no case-insensitive collation in PostgreSQL. Dunno if that has been fixed yet.

Re:*Cough*

[coryking]

Indeed I did mark it unique. However, in PostgreSQL, "Jacuqes CHESter" and "jacques chester" are two different values. In MySQL, they are the same value.

Re:*Cough*

[Richard_at_work]

Expired user accounts?

Re:*Cough*

[palegray.net]

Mod parent down to failure to understand case insensitivity in MySQL even after the several posts in the same thread discussed it.

Re:*Cough*

[daveime]

What is wrong with ?

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

It will still use the same index (assuming you have one) on the username column as

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

The point is, while case sensitivity might be the more-correct purist programmer's / DBA's outlook on things, the pointy headed bosses' outlook is that 'coryking' and 'CoRyKiNg' ARE THE SAME, and you suck as a programmer if your system can't even deal with this simple bit of fuzzy matching.

I'm happy with MySQL the way it behaves now, and if I really want to be pedantic, I can use the BINARY('') matching at no extra cost in performance, despite the FUD coming from the Postgre camp.

Re:*Cough*

[Anonymous Coward]

The way I do it in real databases, so I can have a case sensitive field, and a case in sensitive search is to create a column populated with a update and insert triggers for upper case names.

Then when I do the search I change the case of my string to upper case and search on the upper case column.

Re:*Cough*

[WuphonsReach]

Or you could have told PostgreSQL to do a case-insensitive search on that SQL statement.

See [NOVICE] Case Insensitive Searching?.

Re:*Cough*

[nandix]

In MySQL, "coryking", "CorYKING" and "CORYKing" may or may not be all the same, depending if the datatype is binary (they wouldn't be the same) or non-binary (the could be the same or not, depending on the charset and collation). You probably had a case insensitive collation on MySQL. I don't know much about Postgresql so I don't know what could have changed on your schema there, but the bottom line is that MySQL *is not case-insensitive*, individual string data types can be case sensitive or insensitive, depending on your application needs. It really pays to RTFM :)

Re:*Cough*

[coryking]

Well, yeah, obviously I know that. But that ILIKE doesn't help much with the UNIQUE index, does it :-)

How protected are they?

[Mr. Underbridge]

As many people dont understand GPLed code still has an owner.

It may have an owner, but that owner gave an unlimited redistribution license to a whole lot of people (provided those people redistribute via GPL). Once that cat's out of the bag, it's not going back in.

The only thing they really can do (that any other GPL licensee can't) is re-license the code under alternate licenses that are more permissive than the GPL.

Independent of that mysql may still be a trademark.

True. But that only applies to the branding stuff, not the code.

The most relevant example is probably CentOS, which is a binary compatible clone of RHEL. Only difference is any material that says "Red Hat" or RHEL.

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

Did they? I'm pretty sure non-compete clauses that require people not to leave, work for competitors, etc are illegal in California where Sun is headquartered. At least many such contracts have been found to be so. They might pay attractive retention bonuses, but they can't force anyone to work for them, slavery being illegal and all. So I'm not so sure how much protection they can really have. I also wonder how one would go about restricting anyone's ability to fork.

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.

Perl?

[Anonymous Coward]

Why is someone still writing a book on Perl and web app development?

What's next "Counter terrorism with cauldrons and catapults"?

Re:Perl?

[daveime]

Because sometimes your web application needs to do something more than ?

1. SELECT * FROM TABLE
2. Display * in a bloody awful HTML template

Anything more than and PHP will only yield tears, depression and suicidal tendencies.

Besides, stealing Perl syntax and merely reversing the order of the parameters does not a language make ... now get off my lawn.

Re:Perl?

[Anonymous Coward]

Ah yes, I forgot:

1.1 Run it through a highly-obsfucated, psudo-object.
1.15 Bless you!
1.2 Try to find a developer who is less than 30 and interested.
1.3 Worry about namespace.
1.4 Wait for Perl 6.
1.5 GOTO 1.3 for 9 years.

Is that some crabgrass I see over there?

Re:Perl?

[daveime]

What is this obsession with namespaces ? And why don't you think perl can't do it ?

require "SomeModule.pl"

&SomeModule::SomeSubroutine;
$SomeModule::SomeString = 123;
%SomeModule::SomeHash{Key} = Value;
@SomeModule::SomeString[2] = 456;

And guess what ... within the module itself, you can refer to those variables and subroutines WITHOUT the namespace prefix !!!

Are are you one of those coders who puts everything into one humungus source file that is 27MB in size ?

Surely it goes both ways?

[Keeper Of Keys]

What would stop Sun from merging any interesting development made on any of these forks back into their version?

Re:Surely it goes both ways?

[mr3038]

What would stop Sun from merging any interesting development made on any of these forks back into their version?

The fact that Sun bought the MySQL for acquiring rights to the source. That allows them to sell MySQL with licenses other than GPLv2. If they merge code from any open source fork (they're all GPLv2 because that's the only choice MySQL license allows for a fork), then Sun would be forced to distribute under GPLv2 only. Clearly this is not what they want because they paid $1,000,000,000 for the source. If they wanted GPLv2, they had it for free (as in beer!) already.

Re:Too specific, too narrow

[daveime]

Although in kdawson's case, it's usually the SAME story again three days later.

Good precedent for the customer though

[Anonymous Coward]

Investors might not be able to become billionaires but customers can be sure that the code base is not going to disappear.

It's better for society in general. I can live with the odd rich person not being so rich.

Yep, I was afraid of this.

[PontifexMaximus]

SUN can't do anything with Open Source but fuck it up. Had they left MySQL alone we wouldn't have a half dozen forked versions. I'd also know that MY current version won't suddenly up and jump the shark into obsolesence because of this.

PostgresQL here I come.

MariaDB

[Anonymous Coward]

Looking at MariaDB, they are going to keep it in line with the stable release of MySQL, add some new features, and use Maria as the default storage engine.

It will stay compatible with the 'main' MySQL.

It looks like changes on this fork may well make it back to the main MySQL code, so it's almost as if Monty is still working on the normal codebase anyway. I suppose he's now doing what he wants instead of Sun?

You can also...

[coryking]

At least in PostgreSQL create indexed functions. In other words, you can create a unique index on LOWER(username). I'm sure the other guys let you index functions too. Either way :-)

May have outgrown your hosting

[tepples]

And now pretend that you are, like many thousands of other people, hosted in a place that doesn't offer it.

If you're using MySQL on a shared hosting plan, and you've about to outgrow MySQL, then you may have outgrown your hosting plan. For example, Go Daddy offers MySQL on shared hosting plans, but it offers both MySQL and PostgreSQL on virtual dedicated server plans. Start porting your bespoke software now on your development server, so that you can switch once your 12-month shared hosting commitment is up for renewal. Just be glad to even have MySQL; you could be limited to the SQLite database module for PHP.

So?

[coryking]

Honestly, if you are at the stage where you are tossing around words like "high-availability", it is time to actually spend cash on a big-boy RDBMs. PostgreSQL is awesome, but it can only scale so far.

If you went MySQL, yeah you can do crazy load-balanced databases out of the box, but it will cost you as much in developer time to hack around the *other* limitations in the product that it would be cheaper to buy a real database.

MySQL is only free if your developer time is not. Good DBAs aren't cheap and MySQL is needs more developer time to work around its limitations than any other database (in my humble opinions).

Re:So?

[Slashdot Parent]

Good DBAs aren't cheap and MySQL is needs more developer time to work around its limitations than any other database (in my humble opinions).

I like Oracle a lot, but I'm not sure I buy your argument that there is a cost savings realized by using it.

Here is a TCO analysis that we must obviously take with several heaping grains of salt considering its source, but it puts the numbers to my thoughts on the subject.

Oracle RAC is monumentously expensive, so if you can get away with MySQL cluster, I think it's advisable in many circumstances.

The TCO comparison from MySQL doesn't even address DBA time, which as you thoughtfully pointed out, is not cheap. But have you ever been to an Oracle shop that lacked a small army of expensive Oracle DBAs?

For what it's worth, most of my clients (i.e. the ones who can afford me) use Oracle, and feel compelled to point out that I've sure seen my share of hacks needed to make Oracle behave, too. ;)

Re:So?

[coryking]

I don't have much experience with Oracle, honestly. But what little experience I've had has led me to believe it is quirky in its own right. But I think it might be that way because you can pretty much get it to do anything...

It also seemed insanely complex. The amount of garbage its installer put on my disk (in non-standard locations) was amusing. The ugly skin the used was also amusing. But damn, the integration with visual studio was nice!

Basically, I felt like I was at one of those amusement park rides that have the "you must be this tall to go on this ride", only "your applications must be this tall to use this software". And that was their free version too!

Moral? Maybe that there isn't a good free database for that level.

Re:So?

[Slashdot Parent]

Moral? Maybe that there isn't a good free database for that level.

Well, I would argue that MySQL is a reasonable substitute when full-blown Oracle is not needed, but most PostgreSQL users are too stuck in the past to see that MySQL has grown up and left postgres in the dust when it comes to replication and clustering.

I realize that postgres is getting real replication "real soon now" (it's only slipped one release... so far...), but until the postgres team admits their error of pushing replication/clustering outside of the database engine and gets serious about putting a real solution into the DBMS where it belongs, postgres cannot be considered a serious database in a multi-server environment.

Re:So?

[coryking]

Replication and clustering are only one component of the whole product. The sheer amount of legwork required to make MySQL performant on all but the smallest use cases make it fairly costly. It also has so many 'isms attached that if you aren't careful you can dig your database into a MySQL-only world that is impossible to migrate out of.

I also wonder how many people have to cluster their MySQL stuff because the database itself just doesn't perform very well. I wonder if they were using a different product if they'd even have to cluster at all.

it's only slipped one release... so far...

Probably because it is a hard problem, limited developer time, and the fact there are much cooler features the community wants like materialized views (which would probably make many setups not need clustering at all!).

Perhaps the worldview of MySQL folk has been tainted by how poorly it performs. All they think of is "OMG it doesn't cluster" but maybe if they looked at the tools PostgreSQL offers, they'd see clustering might not even be necessary on PostgreSQL. Maybe PostgreSQL doesn't have good clustering yet because in many cases, people really just dont need it!

Re:So?

[Slashdot Parent]

I'll admit to liking the warm fuzzy of knowing I can always throw more hardware at a problem. Hardware is cheap. In many cases, really really cheap.

The fact that I can't get a reasonable pgsql cluster at any price is a big turn-off for me. Anyhow, I'm sure it has plenty of quirks as well that you're just used to by now. I even see the venerated Oracle come up with some really .. um.. "creative" query execution plans every once in a while. Yes, still.

Re:So?

[coryking]

Heh. What fun would our jobs be without creative execution plans? I mean, we don't hunt tigers anymore, so we have to get our "kill" somehow and I'll take "trick the query planner into doing what I want" as a substitute--that or finding a good parking spot.

Hardware is cheap.

'Tis true. You can by trash webservers and string them out across a load balancer and be fine. It is much cheaper to by more webservers than spend developer time squeezing more performance out of code.

The database server is the one thing you can't cheap out on. You can only make that single thing bigger and bigger.

That said, never clustered a database so I dont know its pitfalls or gotchas :-)

By the way, EC2 + Database? Does it work? I've looked around for case studies, war stories, or anything. Are people doing it? Is their stuff fast enough? Don't you have to put the table on those "perma-disks" so they don't get wiped? Are those some SAN thing or are they like NFS? The IO is important for a database, and there was little info about what, exactly, those perma-disk mounts actually are. And don't they meter disk IO?

It looks intriguing, but I need answers and can't find them :-) I know it wouldn't be cost effective to run the database server "offsite" and run the web stuff in the cloud. You'd need the database "in the cloud" with the webservers...

Re:So?

[Slashdot Parent]

By the way, EC2 + Database? Does it work?

Really depends on what you're doing. You're on network storage, so random reads carry a large cost. On the other hand, your storage is behind a large, durable write cache, so writes are comparatively low-cost. Turns some I/O analysis on its ear, no? ;)

And, yes, EBS disk IO is metered, but the cost will be less than you think due to application caching, OS caching, and your OS's IO scheduler coalescing smaller requests into larger ones. See Projecting Costs here.

All that said, I think that the vast majority of applications that have databases in EC2 do because the rest of the application is also in EC2. For a heavy IO database centric application, I've found that there really isn't any substitute for being close to the bare metal.

I suppose if your working dataset would fit into the 15GB of memory of an extra large EC2 instance, you could be less limited by the latency of EBS reads. MySQL cluster is designed this way (to have most of your data in memory), so obviously your cluster would survive the loss of a node despite the data being in RAM.

I suppose the EC2 architecture really favors MySQL over Postgres because of that. Well, and also I am under the impression that Postgres can answer fewer types of queries (such as count(*)) from the index due to MVCC. Having to go out to the data means that IO penalty hurts Postgres more.

Re:So?

[coryking]

Well, and also I am under the impression that Postgres can answer fewer types of queries (such as count(*)) from the index due to MVCC.

This is an aspect they are planning to improve. Somehwere on their roadmap, I recall reading they were gonna get it so certian queries can be answered right out of the index. But to take a dig at you, I'll point out Postgres can do crazy things with indexes that MySQL can't--like combine two separate indexes for a query (so you dont have to create a multi-column index) or do some weird scan on them for joins. MySQL only seems to have basic kinds of indexes.

COUNT(*) is actually a tough cookie on any MVCC. I suspect they will have a way to get an approximate count of a large dataset without a sequential scan... most people who do COUNT(*) on a large set of data are doing it for pagination or just a string of text saying "059345 results found". In those cases you can be off a few records and live to tell the story.

Btw, I fooled with that planner you linked to a while ago. How the hell do you come up with a number for their IO stuff? Like, is there a magic command on a unix-like system that will give some number you can plug in?

Re:So?

[Slashdot Parent]

Btw, I fooled with that planner you linked to a while ago. How the hell do you come up with a number for their IO stuff? Like, is there a magic command on a unix-like system that will give some number you can plug in?

The billing information for EBS IOs is done from their hardware, so it really measures every single IO. If you want to test out how much I/O your EC2 instance is doing (or if you want to test on your own machine), you can use the iostat utility.

Re:So?

[coryking]

Why? Just out of curiosity, why are they dinging you for IO? Is it because of the fact it is on network storage?

Re:So?

[Slashdot Parent]

I don't have any insight into their cost structure, but your reasoning sounds reasonable to me. :)

Re:So?

[Anonymous Coward]

There's a point where hardware becomes more expensive than developers. Last year I spent a couple months porting our app from database queries to a memory resident key-value store. That freed up about 150 machines across three datacenters, which means about $150K we don't have to spend on new servers and racks this year, covering my salary and overhead for the better part of a year.

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!

I agree

[coryking]

There are a lot of knobs to turn. They are somewhat well-documented knobs, but knobs none the less. MySQL ships with like four sample configurations.

That said, the best solution would be to make it self-opimizing. It already tries to self-optimize its query plans (i.e.: "We aren't gonna support hints on indexes... if the query planner needs hints, the query planner is broken"). It could do something similar with its configuration. But honestly, that would take development time away from more important things like materialized views or WITH queries. I'd much rather have stuff like that.

By the way, you don't have to edit the config file by hand, you can actually edit it from the comfort of your desktop in PgAdmin and even trigger a reload of the file.

Um, what?

[Estanislao Mart�nez]

You seem to want to encourage a mindset that separates people who work with DBs and programmers who more often than not, work with these "empty" values in their code, and expect the same behaviour from the DB. Sort of counter intuitive to a lot of us, especially those of us that have to perform BOTH programming AND DBA tasks.

The problem with what you're saying here is that, in the name of programmer convenience, you're not addressing any of the problems that an RDBMS is supposed to solve. Most critically in this case, logical data integrity. Do you understand what problem RDBMS features like constraints are supposed to solve? Do you seriously want databases to stop solving those problems in the name of being more similar to a tool you're more familiar with, that does not solve that problem?

I propose you stop telling us all how databases should work, and learn some elementary database theory.

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.

And then your buggy programs that fail to specify a value for that column cause the silent insertion of bogus data into your database; data that we could prove at that moment to be wrong. Then nobody notices for a long time, run queries against the DB and get incorrect answers. For example, they fail to specify the column for the amount of a cash transaction, which means that a row with $0 is inserted, and all reports that rely on computing the average amount per transaction are hopelessly wrong.

Sorry if I missed something critical, but it seems like you are trying to put all the load onto the programmer just so you can have a "cleaner" table definition?

No, we're trying to make sure the data doesn't get into a state where it's hopelessly and irrecoverably incorrect. It's got nothing to do with conspiracies to "put all the load onto the programmer" to get the tables to be "clean" or "elegant" or anything of the sort. It's the damn simple fact that it is very often the case that we can tell beforehand that a column in a table must never have be null if the table's data is to be correct, yet there is no sensible default value. Like, you know, my example of the dollar amount column in a table storing financial transaction details.

It is all about community

[dgallard]

In a related thread talking about PostgreSQL, it was written:

> 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.

In MySQL it is quite nice, for example, that '', NULL, and 0 all tend to have the same semantics in certain contexts. Or that on the command line, you can enter a comment beginning with any of //, --, 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.

Look SQL itself is sucky. All of the RDBMs must cope with that. So the least one can do is provide system level ease of use. MySQL does that quite well, which is one important reason it has a thriving community.

Sometimes you get both - good design and community. Witness Python. I have not had reason to develop with Python but when the Python book first came out, unlike my initial negative reaction to the Perl Book, I thought "Now THAT is a good language. The manual is very understandable and the design is clean." The fact that a solid community arose is icing on the cake for Python and an *additional* fact about Python culture. There are excellent languages, such as Common Lisp, that failed to develop a vibrant community so excellence of language is neither a necessary nor sufficient condition to foster community.

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, the complexity of building a complex solution in the RDBMS space, and, quite simply, because it is so very reliable.

Don't get me wrong, if I had my druthers, I might use Postgres. But, for the 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 easy use and, more importantly, EASY TO START USING. Then, once the community evolves, things feed on themselves. You get lots of example code, good documention, etc. You are off and running.

Disclaimer: I have not used Postgres very much. I have and do use both Oracle and MySQL a lot. But I tried PostgreSQL (OK, I'll call it that) enough to be frustrated by its lack of community and a

Elite is mostly hubris.

[reiisi]

The ability to understand the difference between ++i and i++ comes by experience to those for whom it makes a difference. The ability to recognize and appreciate a decent RDBMS comes by experience to those who use such. We can talk about such things, but, as is typical, the set of those who talk and the set of those who do tend to be somewhat disjoint sets.

Designation as elite comes from the person so designating himself, or, perhaps, some certifying organization which certifies primarily based on tests. Experience is a hard thing to measure, and an even harder thing to certify meaningfully. Tests can only certify a baseline competence.

Elitism tends to declare itself beyond competence. Thus, elite is mostly hubris.

Hubris (in the sense of self-confidence) is not entirely evil, and I may be conflating "l33t" with "elite" to an extent with which you would not agree, but elite is still mostly hubris.

I would rather talk about dedication to ideals such as constantly refining one's skill set, and service.

Some people call that professionalism, but that's yet another word that means different things to different people. (Some managers think it's unprofessional to perform uncharged service, for instance.)

Re:Elite is mostly hubris.

[mlwmohawk]

Designation as elite comes from the person so designating himself

Well, actually comes from morons who call you "elitist" or an "elite" for saying that one product is better than another or that "good enough" is a fools game.

There are lots of real reasons why MySQL is a bad database, and for that mere statement I am called "elite" or "elitist." Sorry, maybe I am "elite" but I have worked hard in my career to know things and have knowledge from which I make decisions. I don't blindly say something is "good enough" without being able to quantify those decisions, and MySQL is not "good enough" on most all measures.

Re:Elite is mostly hubris.

[reiisi]

Hmm.

Trying to remember the contexts where I've read, heard, used the word elite.

My friend who joined some elite branch of the military is probably the most representative instance. (The branch where they pick up their agents with bungie cords dangling from reconnaissance jets or something like that.)

If your friends call you elitist for naming the failings of MySQL, maybe you need to spend time with different friends. :-/

I don't exactly disagree about MySQL not being good enough, but then most software really isn't good enough, either. PostGreSQL is a good direction to migrate if migration ends up being necessary, but I was mostly commenting on the word "elite".

Myself, I'm from the camp that believes that ++i is more often what people mean when they write i++, and that people would benefit at a fundamental level to understand what they are saying, especially when writing software. MySQL used to be much easier to get started with than PostGreSQL, and most people who thought they wanted a database, seemed they really mostly expected some cheap semi-persistent content-addressable store.

It's a different world now. MySQL has improved their underlying tech, PostGreSQL is easier to get started with and has improved the underlying tech. The money Sun spent for MySQL was a huge mistake. Unbelievable mistake, typical of what tends to be done just before the stock (etc.) market starts a major correction.

But, I'm not sure the investment should be just abandoned. There is market value in the brand, still, and the licensing compatibility issues (among other things) prevent Sun from just bolting a compatibility interface on top of PostGreSQL.

Anyway, I was just commenting on the word elite.