Gary Pendergast writes "Monty Widenius, the 'father' of MySQL, has created the the Open Database Alliance, with the aim of becoming the industry hub for the MySQL open source database. He wants to unify all MySQL-related development and services, providing a potential solution to the fragmentation and uncertainty facing the communities, businesses and technical experts involved with MySQL, following the news of the Oracle acquisition of Sun." Related to this, an anonymous reader writes that "MySQL has announced a project to refactor MySQL to be a more Drizzle-like database." Update: 05/14 20:50 GMT by T: Original headline implied that this was a project of Sun, but (thanks to the open source nature of MySQL) it's actually Monty Widenius — no longer with Sun — leading this effort.
by Anonymous Coward
on Thursday May 14 2009, @03:20PM (#27956169)
Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.
Did you go out there and talk to the Oracle? Did the Oracle come out into the sunlight and say anything at all...any gestures, groans, wild waving of hands, rolling of eyeballs...anything?
Can we go out and talk to the Oracle in person?
Dammit man, time is running out - we must speak to the Oracle....now, not later, right now!!!!
I don't get why they treat Oracle like AOL acquiring Netscape. It is a database development company which has no solution to fill MySQL'es place if I haven't mistaken.
I think after these incidents, large companies will think 1 billion times when they got the idea of acquiring an open source project. They treat Oracle like AOL for God's sake.
Freightliners [freightlinertrucks.com] and Vespas [vespausa.com] are both vehicles.
Oracle is what you use if you have hundreds of millions of dollars, a team of DBAs, and your need for data storage is such that downtime is measured in thousands of dollars lost per minute.
MySQL is what you use if you've got ten employees (one of which knows a bit of PHP) and sell motorcycle parts over the internet and you don't feel like an ebay store would quite meet your need.
They're both great products (I assume, I'm not a DBA and haven't messed with oracle). They're both RDBMS's. They both run on just about any modern platform. They're not used for the same stuff.
It is a database development company which has no solution to fill MySQL'es place if I haven't mistaken.
Oracle has a number of lighter DB products, including Oracle Express Edition (XE) which is free (as in beer). They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does, but certainly they have a number of products whose market niches at least overlap with that of MySQL.
(Also, Oracle is a lot more than a database development company and has certainly been more aggressively pushing into other areas; I suspect that their acquisition of Sun was more focussed on the non-MySQL parts of Sun than on MySQL.)
They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does Regular Oracle tables and index-organized tables have completely different physical implementations, and bitmap indexes have a completely different physical implementation from regular indexes. They're all ACID, though.
OK but none of the products gets hit because MySQL exists right?
Since they have overlapping niches, probably some of Oracle's products, particularly at the low end, take a hit from MySQL. Since even their free low-end products are designed to be compatible with and provide an upgrade path to their pricier DB offerings while its probably as easy to go from MySQL to PostgreSQL-based EnterpriseDB, DB2, or MS SQL as from MySQL to Oracle, their certainly might be reasons why they'd rather, over the long term, e
For apps that need basic SQL functionality and aren't particularly-high load, I use SQLite. For app that need advanced SQL or high load, I use Postgres. I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).
Many of us MySQL users see your Postgres question the same way: why use Postgres? There's 10 users of Postgres, and if I randomly toss both names into a room, I don't have to explain what MySQL is. Hell, half think I said "postfix" and leave the room.
What's MS SQL? OK, I'm kidding, but it makes me wonder if you've checked MySQL lately. I haven't had a reason to check Postgres, so I maybe just-as-satisfied with MySQL as you are with Postgres.
MySQL works for many of us. We don't want to switch to a d
I didn't ask if it worked. I asked in what scenario it would be a superior option (to the well-informed application architect, of course). The only real reason you gave is that you don't know much about Postgres. That means you're not really qualified to answer the question.
Does it scale better? Does it have better security? Is it easier to manage in some way? Is there a killer feature its two closest competitors lack? Those might be actual answers to the question. "I don't know much about it" is not an answer.
It's certainly commonly perceived that Postgres will scale better, and that it has a rather complete featureset. If this is indeed the case, I can't see a reason to select MySQL for a new project. Why limit yourself?
People like you are undermining the industry. You straddle around claiming to be a database developer with x years under the belt, but you are in fact putting your clients data in grave danger and when shit finally hits the fan on your mysql installation you are going to wish you listened to the people who knew better.
...I saw in one presentation their chief architect did. They had no complaints about it; apparently it scales brilliantly as long as the db schema is very simple.
For heavy-weight databases though, I gather it's not so good.
> I asked in what scenario it would be a superior option (to the well-informed application architect, of course).
Of course because MySQL's root password comes empty so the Agile developers avoid losing their costly time waiting for the local database nerd configuring the permissions and bothering the team with more passwords to remember....
I asked in what scenario it would be a superior option
I'm with you on that - in the last 7 years, I've used PostgreSQL exclusively for projects that were under my control. I'm subscribed on the mailing lists, I know about all the misconceptions regarding performance, and I know that MySQL is nowhere near as reliable and professional as PG.
But since you asked: I'm still running MySQL on most of the servers, and the reason for that (the only reason) is third party support. When you're installing a web-based CMS, or bulletin board, or bug tracker, or gallery, or
PostGres competing with MySQL is like alpha competing with Intel.
Even though IMO PG is technically superior in every way, MySQL is more widely supported, both directly and indirectly as a backend for many systems.
In fact, I am building a personal website and I want to add a message board. Guess which database backend every single one of them supports?
And until everyone else above me in the supply chain overcomes their collective inertia, my hands are tied because as of yet I do not have sufficient temporal
Look-up a bunch of cheap hosting providers. How many have postgres?
Fewer than offer MySQL, but enough that if PostgreSQL is the right DB choice for technical reasons, this just means you don't choose one of the hosting providers that don't support PostgreSQL, not that you choose MySQL.
(Assuming, of course, that you are building a web app where a discount shared hosting service is the right choice to start with; of course, not all apps for which a DB is needed are web apps, and not all web apps are those fo
Is sounds like you are saying that because it gets a lot of press causing a lot of people to know the name, then it must be the best database server out there. And it is more compatible and works better because of that? WTF? What the hell do you mean by compatible by the way?
More people know or knew how to program in Visual Basic than in Java or C or C++. Does that mean it is a better programming language and more compatible? You are going to tell me that what I just wrote doesn't make sense. And you would
Many of us MySQL users see your Postgres question the same way: why use Postgres?
Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.
Take a look [mysqlperformanceblog.com] at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?
I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.
Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy [mysql.com]. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."
Now compare with the Postgres manual page describing their ACID implementation [postgresql.org]. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.
Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?
MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.
This is one major reason why I refuse to use PostgreSQL: VACUUME [postgresql.org] for the fail.
Why the hell do we have to hand hold PostgreSQL to get it to clean up after its self? MySQL has no problem doing it on its own nor does any other databases that I know of require such an operation. Its also quite lame to run a dedicated daemon to monitor and tell PostgreSQL to clean up its mess. Another thing which was a past problem was the user permissions were just terribly implemented making it a complete joke to use for mu
"Fortunately, The Auto-Vacuum Daemon monitors table activity and performs VACUUMs when necessary. This eliminates the need for administrators to worry about disk space recovery in all but the most unusual cases."
You'll be glad to hear about the autovacuum [postgresql.org] built into PostgreSQL versions 8.1+. (Ok, so it's not on by default yet. One configuration switch.)
I could give you the good reasons for having VACUUM run separately, (Actually, it's often easier to know from outside when your database is going to be busy...), but in general I agree having to run VACUUM was a pain. I'm glad it's no longer needed.
For instance if you never delete from a table there's no need to bother trying to vacuum it.
Not quite. Because of the way postgres operates (MVCC) UPDATEs will result in space appearing in table structures too. With an MVCC based DB nothing is updated in-place (actually, in any good DB nothing is updated in-place, but with MVCC this is more obviously implied by any good description of how things work with multiple distinct transactions present). When a row is updated new version is added and the old version is removed when the transaction is complete and no other transactions might refer to the old copy. This has significant advantages for some use cases and loads, and some disadvantages in other
The wikipedia page (http://en.wikipedia.org/wiki/Multiversion_concurrency_control) isn't a great description though there is a bit more relevant information in http://en.wikipedia.org/wiki/Snapshot_isolation [wikipedia.org].
I've not used postgres much in anger, so I'm no expert, but personally I thought that being able to manually schedule cleanup was a good idea performance wise.
I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).
I work for a Fortune 500 company. We use MySQL with J2EE and Hibernate in a production environment. Postgres would be our fall-back option if MySQL ever stopped doing the trick for us, but it scales well to thousands of users.
MySQL can easily be configured for use as a production-quality database. We also use Oracle and DB2 on an i5 for certain purposes, but our biggest app (in terms of company scope and $$) employs MySQL in the back-end.
That's certainly a good thing, i'll give you that.
it plays nicely with Perl and PHP,
I just threw up. As my keyboard shorted in its vomit bath, it outputted a random string of characters and symbols, which just happen to execute without warnings when piped to perl.
I just threw up. As my keyboard shorted in its vomit bath, it outputted a random string of characters and symbols, which just happen to execute without warnings when piped to perl.
Every fucking time there's a MySQL article, you Postgres trolls come out of the woodwork. Give it a fucking rest, already. We're talking about MySQL, not your beloved Postgres.
Fair enough. However...
WHY use MySQL? Gee, because it's well documented,..., there's good documentation and websites, etc etc etc. You can't say the same for Postgres.
That's bullshit. The PostgreSQL is among the very best I've ever seen for any piece of software, open- or closed source. And I've seen _lots_ of it...
WHY use MySQL? Gee, because it's well documented, it plays nicely with Perl and PHP, it's available on nearly every corporate hosting package, there's good documentation and websites, etc etc etc. You can't say the same for Postgres.
IME, you can pretty much say all of that for Postgres, Postgres "official" documentation and third-party "how-to" information, on the web, in dead trees, and otherwise, is as good, or better, than MySQL documentation (though the total volume is somewhat lower, the coverage and q
MySQL is not well documented. It's got horrible documentation. Granted, it's got lots of it (and everything is there somewhere), but it's all horrible: Specifics of syntax and usage are often spread through half-dozen pages for a single command, with no linkage between them in the HTML.
As for 'playing nicely'... You've obviously never tried to get the Perl DBI working with MySQL on RedHat. As far as I can tell, the process is 'Recompile it. All of it. Again.' I spent two weeks trying to get it to wor
MySQL is well documented so that all the bugs are turned into features:
Mein Broder: So, in MySQL, when you exceed the maximum size of a TEXT column, does it throw an exception, or does it just truncate the data to fit?
Me: Well, it being MySQL, it will probably do something differently on Tuesdays than it does on the vernal equinox... but it probably will throw an exception and bitch about how you suck at data planning. Which is the proper thing to do, because who would want their database silently truncating data?
Mein Broder: In this case, I'd actually prefer it, 'cause otherwise I'd have to programmatically truncate it myself. These data aren't really that important, and truncating would be acceptable. It would be nice if I could be a lazy programmer.
Me: I think you're out of luck. But let's take a look:
MySQL Manual -- If you assign a value to a BLOB or TEXT column that exceeds the column type's maximum length, the value is truncated to fit.
Me: Astounding. Your desire to be a lazy, shiftless programmer has been facilitated by other lazy, shiftless programmers who have built the world's most rickety database management system.
I'll admit, I haven't followed MySQL that much but i'm confused as to the state its in now. With the original founders going off and doing related stuff it seems pretty fragmented.
No one can, you got several companies having their greased fingers involved, you got several different licensing systems for the same code base and the original developers all split into new forked projects.
It was during MySQL AB's time that MySQL began a stange play with the community by first dropping official community binary builds, and then severely delaying source code releases as well (while supplying commercial clients with more stable and up to date releases).
It was again during MySQL AB's time when the announcement came that MySQL's source code base will start to "close down", by releasing many new features only commercially, and with no open source code. When Sun bought MySQL AB, they reversed those policies and stood behind MySQL being open, without exceptions.
Now Mr. Monty Widenius has taken the money Sun paid for MySQL AB, and used it to open a new company and an "Open" alliance which is "designed to become the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other".
If even Mr. Widenius has noble intentions regarding MySQL, his past in MySQL AB and his current interaction with Sun/Oracle seem to leave another impression.
1. Monty starts db called MySQL, trademarks and has copyright 2. Monty sells trademarks and copyrights to Sun (presumably for a ton of cash) 3. Monty leaves Sun 4. Monty forks MySQL calls it MariaDB
So in the end.
Sun has: 1. A trademark 2. Rights to the code 3. Right to sell MySQl under any license
Monty has: 1. GPL'd code he does not own 2. Credibility as the guy who knows about this 3. The ability to continue selling support services
So in OSS when you buy a product you don't really get too much do you? (At least if you can't hang onto the developers)
> So in OSS when you buy a product you don't really get too much do you?
I think they got a lot from it: Monty is completely hamstrung because he doesn't own a line of the code in his new "Open" database. Unless he rewrites from scratch he is stuck with GPL even if he wants to give his code to his own wife. And that also means that no serious commercial company can use it because even the drivers are GPL (*not* LGPL) which means as soon as you touch it even to open a connection your own product turns to GPL (unless you buy a license from Oracle).
IMHO, the first thing that needs to happen (and which should have happened years ago) is that the MySQL GPL drivers need to be clean-room rewritten so at least you can link non-GPL code with it. Until then I've got no interest in it and it loses to PostgreSQL before I even get to thinking about a technical comparison (and please note: I've got nothing against GPL in general, I just don't want it forced inside my own processes by my database).
If they don't come up with a pure technical reason, a proof for forking the project rather than "big company hate" or conspiracy theories, they are already taking this decision politically.
If they think Oracle purchased Sun just to kill their project for 7.2 billion dollars in such state of Global economy, they are bordering megalomania.
PostgreSQL (Score:4, Insightful)
Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.
Re: (Score:3, Informative)
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
Re:PostgreSQL (Score:4, Interesting)
Slony-I is asynchronous. Read postgres' excellent documentation [postgresql.org] for some other possibilities.
You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.
Parent
Re:PostgreSQL (Score:4, Informative)
Slony-I is a dreadful hack that misuses triggers, and doesn't scale past a few nodes.
I'm sorry, but Slony-I is not a serious replication solution.
Parent
Yes, but.... (Score:2)
Did you go out there and talk to the Oracle? Did the Oracle come out into the sunlight and say anything at all...any gestures, groans, wild waving of hands, rolling of eyeballs...anything?
Can we go out and talk to the Oracle in person?
Dammit man, time is running out - we must speak to the Oracle....now, not later, right now!!!!
Re:Yes, but.... (Score:5, Insightful)
I don't get why they treat Oracle like AOL acquiring Netscape. It is a database development company which has no solution to fill MySQL'es place if I haven't mistaken.
I think after these incidents, large companies will think 1 billion times when they got the idea of acquiring an open source project. They treat Oracle like AOL for God's sake.
Parent
Re: (Score:2)
Re:Yes, but.... (Score:5, Insightful)
I thought Oracle was a database? Is it different enough from MySQL to bother keeping both?
If you have to ask that question, just believe us when we answer "Yes."
Parent
Re:Yes, but.... (Score:4, Insightful)
Freightliners [freightlinertrucks.com] and Vespas [vespausa.com] are both vehicles.
Oracle is what you use if you have hundreds of millions of dollars, a team of DBAs, and your need for data storage is such that downtime is measured in thousands of dollars lost per minute.
MySQL is what you use if you've got ten employees (one of which knows a bit of PHP) and sell motorcycle parts over the internet and you don't feel like an ebay store would quite meet your need.
They're both great products (I assume, I'm not a DBA and haven't messed with oracle). They're both RDBMS's. They both run on just about any modern platform. They're not used for the same stuff.
Parent
Re:Yes, but.... (Score:4, Informative)
Oracle has a number of lighter DB products, including Oracle Express Edition (XE) which is free (as in beer). They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does, but certainly they have a number of products whose market niches at least overlap with that of MySQL.
(Also, Oracle is a lot more than a database development company and has certainly been more aggressively pushing into other areas; I suspect that their acquisition of Sun was more focussed on the non-MySQL parts of Sun than on MySQL.)
Parent
Re: (Score:3, Informative)
They don't have anything (that I know of) that does the same kind of multi-backend thing that MySQL does
Regular Oracle tables and index-organized tables have completely different physical implementations, and bitmap indexes have a completely different physical implementation from regular indexes. They're all ACID, though.
Re: (Score:3, Informative)
Since they have overlapping niches, probably some of Oracle's products, particularly at the low end, take a hit from MySQL. Since even their free low-end products are designed to be compatible with and provide an upgrade path to their pricier DB offerings while its probably as easy to go from MySQL to PostgreSQL-based EnterpriseDB, DB2, or MS SQL as from MySQL to Oracle, their certainly might be reasons why they'd rather, over the long term, e
Refactoring Eh? (Score:2, Insightful)
Fo Shizzle (Score:4, Funny)
Myizzle SQL be-izzle lizzleke Drizzle.
why? (Score:4, Insightful)
For apps that need basic SQL functionality and aren't particularly-high load, I use SQLite. For app that need advanced SQL or high load, I use Postgres. I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).
Re: (Score:3, Informative)
Existing products - there's some software packages people like to use from the open source world that are tied to MySQL.
But yeah, if I had any choice, there'd be no instances in which I'd pick MySQL over SQLite or Postgres.
Re: (Score:2, Insightful)
Many of us MySQL users see your Postgres question the same way: why use Postgres? There's 10 users of Postgres, and if I randomly toss both names into a room, I don't have to explain what MySQL is. Hell, half think I said "postfix" and leave the room.
What's MS SQL? OK, I'm kidding, but it makes me wonder if you've checked MySQL lately. I haven't had a reason to check Postgres, so I maybe just-as-satisfied with MySQL as you are with Postgres.
MySQL works for many of us. We don't want to switch to a d
Re:why? (Score:5, Informative)
I didn't ask if it worked. I asked in what scenario it would be a superior option (to the well-informed application architect, of course). The only real reason you gave is that you don't know much about Postgres. That means you're not really qualified to answer the question.
Does it scale better? Does it have better security? Is it easier to manage in some way? Is there a killer feature its two closest competitors lack? Those might be actual answers to the question. "I don't know much about it" is not an answer.
It's certainly commonly perceived that Postgres will scale better, and that it has a rather complete featureset. If this is indeed the case, I can't see a reason to select MySQL for a new project. Why limit yourself?
Parent
Re:why? (Score:5, Informative)
MySQL is better because I know how to use it and it works well enough. If I were to switch to Postgres, then I would have to spend time learning it.
My manager would rather me move some other feature forward rather than replace database A with database B.
When we hire somebody new, it is easier to find candidates who already know MySQL. That matters too.
-ec
Parent
Re:why? (Score:5, Insightful)
People like you are undermining the industry. You straddle around claiming to be a database developer with x years under the belt, but you are in fact putting your clients data in grave danger and when shit finally hits the fan on your mysql installation you are going to wish you listened to the people who knew better.
Parent
facebook uses it (Score:5, Informative)
...I saw in one presentation their chief architect did. They had no complaints about it; apparently it scales brilliantly as long as the db schema is very simple.
For heavy-weight databases though, I gather it's not so good.
Parent
Re:why? (Score:4, Funny)
> I asked in what scenario it would be a superior option (to the well-informed application architect, of course).
Of course because MySQL's root password comes empty so the Agile developers avoid losing their costly time waiting for the local database nerd configuring the permissions and bothering the team with more passwords to remember....
Parent
Re: (Score:3, Informative)
I asked in what scenario it would be a superior option
I'm with you on that - in the last 7 years, I've used PostgreSQL exclusively for projects that were under my control. I'm subscribed on the mailing lists, I know about all the misconceptions regarding performance, and I know that MySQL is nowhere near as reliable and professional as PG.
But since you asked: I'm still running MySQL on most of the servers, and the reason for that (the only reason) is third party support. When you're installing a web-based CMS, or bulletin board, or bug tracker, or gallery, or
Re: (Score:3, Informative)
PostGres competing with MySQL is like alpha competing with Intel.
Even though IMO PG is technically superior in every way, MySQL is more widely supported, both directly and indirectly as a backend for many systems.
In fact, I am building a personal website and I want to add a message board. Guess which database backend every single one of them supports?
And until everyone else above me in the supply chain overcomes their collective inertia, my hands are tied because as of yet I do not have sufficient temporal
Re: (Score:3, Informative)
Fewer than offer MySQL, but enough that if PostgreSQL is the right DB choice for technical reasons, this just means you don't choose one of the hosting providers that don't support PostgreSQL, not that you choose MySQL.
(Assuming, of course, that you are building a web app where a discount shared hosting service is the right choice to start with; of course, not all apps for which a DB is needed are web apps, and not all web apps are those fo
Re: (Score:3, Informative)
Is sounds like you are saying that because it gets a lot of press causing a lot of people to know the name, then it must be the best database server out there. And it is more compatible and works better because of that? WTF? What the hell do you mean by compatible by the way?
More people know or knew how to program in Visual Basic than in Java or C or C++. Does that mean it is a better programming language and more compatible? You are going to tell me that what I just wrote doesn't make sense. And you would
Re:why? (Score:4, Informative)
Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.
Take a look [mysqlperformanceblog.com] at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?
I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.
Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy [mysql.com]. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."
Now compare with the Postgres manual page describing their ACID implementation [postgresql.org]. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.
Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?
MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.
Parent
Re: (Score:2, Insightful)
Why the hell do we have to hand hold PostgreSQL to get it to clean up after its self? MySQL has no problem doing it on its own nor does any other databases that I know of require such an operation. Its also quite lame to run a dedicated daemon to monitor and tell PostgreSQL to clean up its mess. Another thing which was a past problem was the user permissions were just terribly implemented making it a complete joke to use for mu
Re: (Score:2, Informative)
Maybe you should have followed your link:
"Fortunately, The Auto-Vacuum Daemon monitors table activity and performs VACUUMs when necessary. This eliminates the need for administrators to worry about disk space recovery in all but the most unusual cases."
Re: (Score:2)
You'll be glad to hear about the autovacuum [postgresql.org] built into PostgreSQL versions 8.1+. (Ok, so it's not on by default yet. One configuration switch.)
I could give you the good reasons for having VACUUM run separately, (Actually, it's often easier to know from outside when your database is going to be busy...), but in general I agree having to run VACUUM was a pain. I'm glad it's no longer needed.
Re:why? (Score:4, Informative)
For instance if you never delete from a table there's no need to bother trying to vacuum it.
Not quite. Because of the way postgres operates (MVCC) UPDATEs will result in space appearing in table structures too. With an MVCC based DB nothing is updated in-place (actually, in any good DB nothing is updated in-place, but with MVCC this is more obviously implied by any good description of how things work with multiple distinct transactions present). When a row is updated new version is added and the old version is removed when the transaction is complete and no other transactions might refer to the old copy. This has significant advantages for some use cases and loads, and some disadvantages in other
The wikipedia page (http://en.wikipedia.org/wiki/Multiversion_concurrency_control) isn't a great description though there is a bit more relevant information in http://en.wikipedia.org/wiki/Snapshot_isolation [wikipedia.org].
I've not used postgres much in anger, so I'm no expert, but personally I thought that being able to manually schedule cleanup was a good idea performance wise.
Parent
Re:why? (Score:4, Informative)
I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter).
I work for a Fortune 500 company. We use MySQL with J2EE and Hibernate in a production environment. Postgres would be our fall-back option if MySQL ever stopped doing the trick for us, but it scales well to thousands of users.
MySQL can easily be configured for use as a production-quality database. We also use Oracle and DB2 on an i5 for certain purposes, but our biggest app (in terms of company scope and $$) employs MySQL in the back-end.
That's why :-P
Parent
Re:why? (Score:4, Funny)
That's certainly a good thing, i'll give you that.
I just threw up. As my keyboard shorted in its vomit bath, it outputted a random string of characters and symbols, which just happen to execute without warnings when piped to perl.
Parent
Re:why? (Score:5, Funny)
I just threw up. As my keyboard shorted in its vomit bath, it outputted a random string of characters and symbols, which just happen to execute without warnings when piped to perl.
Is the new slashcode out already?
Parent
Re: (Score:3)
Every fucking time there's a MySQL article, you Postgres trolls come out of the woodwork. Give it a fucking rest, already. We're talking about MySQL, not your beloved Postgres.
Fair enough. However...
WHY use MySQL? Gee, because it's well documented, ..., there's good documentation and websites, etc etc etc. You can't say the same for Postgres.
That's bullshit. The PostgreSQL is among the very best I've ever seen for any piece of software, open- or closed source. And I've seen _lots_ of it...
Re: (Score:3)
IME, you can pretty much say all of that for Postgres, Postgres "official" documentation and third-party "how-to" information, on the web, in dead trees, and otherwise, is as good, or better, than MySQL documentation (though the total volume is somewhat lower, the coverage and q
Re: (Score:2)
MySQL is not well documented. It's got horrible documentation. Granted, it's got lots of it (and everything is there somewhere), but it's all horrible: Specifics of syntax and usage are often spread through half-dozen pages for a single command, with no linkage between them in the HTML.
As for 'playing nicely'... You've obviously never tried to get the Perl DBI working with MySQL on RedHat. As far as I can tell, the process is 'Recompile it. All of it. Again.' I spent two weeks trying to get it to wor
Re:why? (Score:5, Funny)
MySQL is well documented so that all the bugs are turned into features:
Mein Broder: So, in MySQL, when you exceed the maximum size of a TEXT column, does it throw an exception, or does it just truncate the data to fit?
Me: Well, it being MySQL, it will probably do something differently on Tuesdays than it does on the vernal equinox... but it probably will throw an exception and bitch about how you suck at data planning. Which is the proper thing to do, because who would want their database silently truncating data?
Mein Broder: In this case, I'd actually prefer it, 'cause otherwise I'd have to programmatically truncate it myself. These data aren't really that important, and truncating would be acceptable. It would be nice if I could be a lazy programmer.
Me: I think you're out of luck. But let's take a look:
Me: Astounding. Your desire to be a lazy, shiftless programmer has been facilitated by other lazy, shiftless programmers who have built the world's most rickety database management system.
Parent
Re: (Score:3, Insightful)
What's the most negative number MySQL can store?
I'm asking because that's your score at reading comprehension.
Who? (Score:5, Insightful)
HEADLINE: MySQL Creates Open Database Alliance, Plans Refactoring
MySQL the database application? It created a new alliance? It plans to refactor itself? Astonishing, if true.
MySQL the software company? Uh, not, because Monty no longer has any connection with them.
You mean Monty did these things. Not "MySQL". His identification with MySQL is pretty strong, but I don't think they'll merge any time soon!
I'm confused (Score:4, Interesting)
I'll admit, I haven't followed MySQL that much but i'm confused as to the state its in now. With the original founders going off and doing related stuff it seems pretty fragmented.
Can someone piece it all together?
Re: (Score:3, Insightful)
No one can, you got several companies having their greased fingers involved, you got several different licensing systems for the same code base and the original developers all split into new forked projects.
MySql - TheirSql (Score:3, Funny)
suggested name change.
MySQL AB ver. 2? (Score:5, Insightful)
It was again during MySQL AB's time when the announcement came that MySQL's source code base will start to "close down", by releasing many new features only commercially, and with no open source code. When Sun bought MySQL AB, they reversed those policies and stood behind MySQL being open, without exceptions.
Now Mr. Monty Widenius has taken the money Sun paid for MySQL AB, and used it to open a new company and an "Open" alliance which is "designed to become the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other".
If even Mr. Widenius has noble intentions regarding MySQL, his past in MySQL AB and his current interaction with Sun/Oracle seem to leave another impression.
what did Sun buy? lessons in OSS acquisitions (Score:3, Interesting)
A lesson in Open Source acquisitions:
1. Monty starts db called MySQL, trademarks and has copyright
2. Monty sells trademarks and copyrights to Sun (presumably for a ton of cash)
3. Monty leaves Sun
4. Monty forks MySQL calls it MariaDB
So in the end.
Sun has:
1. A trademark
2. Rights to the code
3. Right to sell MySQl under any license
Monty has:
1. GPL'd code he does not own
2. Credibility as the guy who knows about this
3. The ability to continue selling support services
So in OSS when you buy a product you don't really get too much do you? (At least if you can't hang onto the developers)
Re:what did Sun buy? lessons in OSS acquisitions (Score:4, Interesting)
> So in OSS when you buy a product you don't really get too much do you?
I think they got a lot from it: Monty is completely hamstrung because he doesn't own a line of the code in his new "Open" database. Unless he rewrites from scratch he is stuck with GPL even if he wants to give his code to his own wife. And that also means that no serious commercial company can use it because even the drivers are GPL (*not* LGPL) which means as soon as you touch it even to open a connection your own product turns to GPL (unless you buy a license from Oracle).
IMHO, the first thing that needs to happen (and which should have happened years ago) is that the MySQL GPL drivers need to be clean-room rewritten so at least you can link non-GPL code with it. Until then I've got no interest in it and it loses to PostgreSQL before I even get to thinking about a technical comparison (and please note: I've got nothing against GPL in general, I just don't want it forced inside my own processes by my database).
Parent
Monty Widenius (Score:5, Funny)
*Opens the envelope*
What do you call a game show host in a goatse pose?
Re:YAY!!!! (Score:5, Interesting)
If they don't come up with a pure technical reason, a proof for forking the project rather than "big company hate" or conspiracy theories, they are already taking this decision politically.
If they think Oracle purchased Sun just to kill their project for 7.2 billion dollars in such state of Global economy, they are bordering megalomania.
Parent
Re: (Score:3, Funny)
Re: (Score:2)