So, based on your evidence, would you like for MySQL to be used to maintain your banking information and that of another 1,000,000 people?
The two problem spaces are completely different, with completely different requirements in terms of reliability and recoverability.
In financial situations, 99.999% right isn't good enough. 99.999999% isn't good enough.
Just to give you a comparison of reliability, on my new test server, I setup postgresql 7.4, and initiated 250 parallel bank transactions, where each client would execute some large number of transactions. In the middle of the test, I pulled the plug on the machine. When it rebooted, the database came up, and had zero problems with corruption or bad tables. Luck? Hardly, it's the way Postgresql is programmed to behave.
Try the same thing with MySQL and MyISAM or innodb tables. While innodb tables may well survive, you will have massive corruption in isam tables, and may well have to revert to backups.
And keep in mind, that Postgresql pales in comparison to either Oracle or DB2 in terms of disaster recovery and what not. It's a sliding scale, and both MySQL and Postgresql are climbing the mountain, but Postgresql has a significant lead in that area.
Come on, can't you see the situation (large company, dozens of people accessing the database) where it would be nice to have a version of MySQL where it just used innodb tables and enforced proper type checking by default? I sure could. I know I could sell MySQL to a whole other segment at work if it could do that.
Choice is sometimes good, but being able to setup the database so as to not give that choice to users is also sometimes a very good thing.
Exactly. When Postgresql reaches the point of being ready for beta, it goes into feature freeze. Code can be changed, but only for bug fixes, or to finish half-finished features. Once it enters rc status, it is now in code freeze, where only actual bugs can be stomped, no more tweaking of beta features.
It results in a remarkable strong release system. Check out the release notes for 7.4.1: http://www.postgresql.org/news/169.html Almost none of these bugs would be considered a show stopper really. Also note that all those bugs were fixed in one single month.
Actually, unless it's changed recently, MSSQL server still has something like a 4k field limit, and Oracle, until version 8, had a row limit of 8k as well, and in version 8 introduced a non-indexable / non-searchable long field, which is still the only place you can store things over 8k.
Also, while you seem to be remembering how badly the Postgresql folks badmouthed MySQL, you seem to be conveniently forgetting the badmouthing that MySQL AB (not the users, the COMPANY) handed out to Postgresql, basically LYING in their online crashme results about Postgresql. While the most aggregious of lies have been removed, and the climate between the MySQL developers adn the Postgresql developers has turned decidedly more civil, there was a time when MySQL, the COMPANY, bad mouthed Postgresql, the community. Remember, there is no company to pay for marketing of Postgresql like the is for MySQL.
Even today, the crashme tests erroneously claim a 16 Meg limit to an insert statement (MySQL's is properly listed as 1 Meg). The reality of the fact on that one is that the buffer MySQL uses to test the database is 16 megs, and when it fills up, the test says "yep, 16 megs is the max." Care to guess what the maximum query size is for Postgresql? Well, there isn't a limit, until the machine runs out of RAM, then SWAP. I.e. no real limit except as declared by your hardware.
There were all kinds of snide and nasty comments about Postgresql in the older MySQL docs, like how code in it wasn't carefully crafted, just tossed in, and how it wasn't well tested.
Those kinds of barbs stung, and there are still a lot of Postgresql users with a chip on their shoulder trying to settle the score.
Postgresql, and MySQL, like every data base has warts. It's just knowing which warts are there so you don't pick the wrong database for the wrong application. In the past, the MySQL party line was that you didn't need the things MySQL was missing, even if you were doing banking style transactions or accounting. That attitude has softened as MySQL has gained both traction and features and the marketing behind it has matured.
What I'd like in MySQL is "per database" settings for things like default table types, ansi compliance (ie. " instead of ` for quoting field names, non-insertion of invalid data etc...) so I could create an HR database that had real relational integrity and enforced it, and didn't allow MyISAM tables, but only innodb.
Postgresql has settings that live "per database" that are quite cool, like "alter database set transaction isolation serializable" and it means that all transactions in THAT database will default to serializable. That kind of per database setting would fix a lot of my problems with using MySQL as a general purpose database.
also, there are ways of making transactions cost VERY little in Postgresql, if that's important, such as putting the xlog on a seperate drive, or even better on a battery backed cache RAID controller, or even disabling FSync. Lately, I'd say Postgresql is an even match for MySQL as a content storage database, and it gets rock solid transactional support as a bonus without me having to worry if I declared my tables properly.
Simply because it's been posted to other threads does not make it redundant, and simply because it bothers you that someone would point out flaws in MySQL does not make it flame bait.
It's also not a troll. Everything in that post is TRUE. While MySQL AB add functionality, they leave little broken parts all over in MySQL, and those parts need to be fixed. It's a reasonable complaint, and one that keeps me from recommending MySQL for most purposes. Sadly, the folks at MySQL haven't seemed real keen on fixing these issues due to backwards compatibility issues.
FYI, the Postgresql Global Development Group does something similar. They release 7.4beta1, 7.4beta2, 7.4beta3, then 7.4rc1, 7.4rc2, etc... Then, after release, they go to 7.4.1, 7.4.2, etc...
The added advantage is that they sort alphanumerically according to the order they were released in.
Postgresql doesn't have a high overhead for each row, it just uses up a bunch of space for things like write ahead logs and the default catalog.
I.e. a default install of 7.3.x will have a 7Meg base directory and a 16 Meg pg_xlog directory before any data has been added. So, while that's nothing to a modern computer with a gigabyte plus size hard drive, it's quite a large amount for an embedded device with a 128 Meg stick in it.
From that perspective, postgresql's data storage usage is friggin' huge.
Firebird is closer to Postgresql in capabilities, and closer to MySQL in terms of size (Postgresql is friggin huge, and sucks up disk space quickly, so it's a bad choice for embedded db applications with limited space unless you're willing to do a lot of hacking to make it "lose weight").
It felt a lot like postgresql to me. I didn't do anything fancy like writing a stored proc or a trigger or something like I've done in Postgresql.
So with the single transaction switch, is it guaranteed to be a coherent backup (i.e. all fk relationships should be clean and all that) or can you get a dirty read? Just wondering. Postgresql's hot backup literally runs in serializable mode, but since the back is read only, it doesn't actually lock anything.
Yep, I just recommended MySQL to a friend here at work, because it was the best fit for his project. It's a simple data delivery system, i.e. 99.99% static data with updates a few times a day at most. And it needed to run on a Windows Laptop. I also recommended firebird for the same project.
Sorry, but until MySQL has a mode where ALL tables are transaction safe, or at least throws an error when you try to create a fk reference to a non-transaction safe table, it's transactions are too prone to data loss due to human error.
It's a good data store, but the guys programming it have to "get it" that transactions can't be optional in certain types of databases, and neither can constraints, or fk enforcement.
MySQL has a tendency of failing to do what you thought it did, and failing to report an error so you know. This is a legacy left over from being a SQL interpreter over ISAM files. It makes MySQL a great choice for content management, but a dangerous choice for transactional systems.
OK, here's how it works. You take your logic for how data gets inserted, and you wrap it in a MySQL java function. You then restrict all update / insert access to said function, taking that ability away from users.
Now, timmy in accounting can program his Vic-20 to insert a payroll record, and no matter how goofy little timmy's BASIC program is, he can't screw up your data, because he doesn't have the power anymore. by restricting all updates to a single code path, you ensure the data cowboys don't go messing up your database.
And, you can then take your java functions with you to your next flavor of MySQL when you upgrade.
Horse puckies. Both Interbase/Firebird and Postgresql have had solid, reliable pls for many many years.
While JAVA stored procs are new to PostgreSQL, the lack of a specific language as a stored proc is pretty silly. PostgreSQL has solid reliable stored procedures in a dozen or so different languages, including perl, ruby, R, tcl, php, and C.
There areas where Oracle outshines Postgresql and MySQL, the are also areas which make it look bad in comparison. To think that the Open Source databases aren't competitive is to only look at one small segment (content storage databases like MySQL) and ignore the others, SAPDB (MySQL MAX??? stupid name, but a good database), Interbase / Firebird, and Postgresql.
I use Postgresql and prefer to it to MySQL, but this is neither the time nor the place to be such a pain in the arse. Do you really think the average MySQL user is gonna be converted like this? The Postgresql crowd is usually a bit more subtle than this. There are plenty of other issues why one might prefer one database over another, and neither MySQL nor Postgresql are the best or the worst for every job.
Note that the 3m microtouch screens can be ordered bonded right onto the front of a CRT. I had a project a long time ago where I had to create / program a kiosk, and all through the project my computer had a touchscreen, and I got so damned used to using my finger for a mouse that when I got rid of that machine I kept touching the screen to do things.:-)
One other thing they did was to put the top row 6 on the LEFT instead of the right. touch typists and most other ergo keyboards put it where it belongs, on the right. If they insist on putting a 6 on the left, why not put a duplicate one on the right where it belongs so touch typists aren't constantly cursing their shiny new MS keyboards.
I solved the problem by just bringing in my own damned keyboard from home at work.
Just remember, Sun has killed it before, and they can kill it again. Just use this simple formula:
p=m1-m2
where
p = profits m1 = money to be made by abandoning X86 Solaris m2 = money to be made by keeping X86 solaris
As soon as p is positive, Sun will cease production of X86 solaris again.
Sun has no loyalty to you, the user, so don't count on X86 Solaris to be there when you need it. We had a dozen or more X86 Solaris servers when Sun dropped it completely a while back, and had just finished converting most to Linux when they said "oops, sorry, we didn't mean to kill it" and brought it back.
Actually, my experience with older Ultra Sparcs (1, 2, etc...) is that they are MUCH faster under linux than under Solaris. About 50 to 150% faster at most stuff. This is especially true if they've got IDE drives in them, as Sun never really seemed to do a great job on the IDE drivers in Solaris (X86 or Sparc)
Postgresql runs about twice as fast on linux on sparc as Solaris on Sparc, for instance.
Slashdot Mirror
So, based on your evidence, would you like for MySQL to be used to maintain your banking information and that of another 1,000,000 people?
The two problem spaces are completely different, with completely different requirements in terms of reliability and recoverability.
In financial situations, 99.999% right isn't good enough. 99.999999% isn't good enough.
Just to give you a comparison of reliability, on my new test server, I setup postgresql 7.4, and initiated 250 parallel bank transactions, where each client would execute some large number of transactions. In the middle of the test, I pulled the plug on the machine. When it rebooted, the database came up, and had zero problems with corruption or bad tables. Luck? Hardly, it's the way Postgresql is programmed to behave.
Try the same thing with MySQL and MyISAM or innodb tables. While innodb tables may well survive, you will have massive corruption in isam tables, and may well have to revert to backups.
And keep in mind, that Postgresql pales in comparison to either Oracle or DB2 in terms of disaster recovery and what not. It's a sliding scale, and both MySQL and Postgresql are climbing the mountain, but Postgresql has a significant lead in that area.
Come on, can't you see the situation (large company, dozens of people accessing the database) where it would be nice to have a version of MySQL where it just used innodb tables and enforced proper type checking by default? I sure could. I know I could sell MySQL to a whole other segment at work if it could do that.
Choice is sometimes good, but being able to setup the database so as to not give that choice to users is also sometimes a very good thing.
Exactly. When Postgresql reaches the point of being ready for beta, it goes into feature freeze. Code can be changed, but only for bug fixes, or to finish half-finished features. Once it enters rc status, it is now in code freeze, where only actual bugs can be stomped, no more tweaking of beta features.
It results in a remarkable strong release system. Check out the release notes for 7.4.1: http://www.postgresql.org/news/169.html Almost none of these bugs would be considered a show stopper really. Also note that all those bugs were fixed in one single month.
Actually, unless it's changed recently, MSSQL server still has something like a 4k field limit, and Oracle, until version 8, had a row limit of 8k as well, and in version 8 introduced a non-indexable / non-searchable long field, which is still the only place you can store things over 8k.
Also, while you seem to be remembering how badly the Postgresql folks badmouthed MySQL, you seem to be conveniently forgetting the badmouthing that MySQL AB (not the users, the COMPANY) handed out to Postgresql, basically LYING in their online crashme results about Postgresql. While the most aggregious of lies have been removed, and the climate between the MySQL developers adn the Postgresql developers has turned decidedly more civil, there was a time when MySQL, the COMPANY, bad mouthed Postgresql, the community. Remember, there is no company to pay for marketing of Postgresql like the is for MySQL.
Even today, the crashme tests erroneously claim a 16 Meg limit to an insert statement (MySQL's is properly listed as 1 Meg). The reality of the fact on that one is that the buffer MySQL uses to test the database is 16 megs, and when it fills up, the test says "yep, 16 megs is the max." Care to guess what the maximum query size is for Postgresql? Well, there isn't a limit, until the machine runs out of RAM, then SWAP. I.e. no real limit except as declared by your hardware.
There were all kinds of snide and nasty comments about Postgresql in the older MySQL docs, like how code in it wasn't carefully crafted, just tossed in, and how it wasn't well tested.
Those kinds of barbs stung, and there are still a lot of Postgresql users with a chip on their shoulder trying to settle the score.
Postgresql, and MySQL, like every data base has warts. It's just knowing which warts are there so you don't pick the wrong database for the wrong application. In the past, the MySQL party line was that you didn't need the things MySQL was missing, even if you were doing banking style transactions or accounting. That attitude has softened as MySQL has gained both traction and features and the marketing behind it has matured.
What I'd like in MySQL is "per database" settings for things like default table types, ansi compliance (ie. " instead of ` for quoting field names, non-insertion of invalid data etc...) so I could create an HR database that had real relational integrity and enforced it, and didn't allow MyISAM tables, but only innodb.
Postgresql has settings that live "per database" that are quite cool, like "alter database set transaction isolation serializable" and it means that all transactions in THAT database will default to serializable. That kind of per database setting would fix a lot of my problems with using MySQL as a general purpose database.
also, there are ways of making transactions cost VERY little in Postgresql, if that's important, such as putting the xlog on a seperate drive, or even better on a battery backed cache RAID controller, or even disabling FSync. Lately, I'd say Postgresql is an even match for MySQL as a content storage database, and it gets rock solid transactional support as a bonus without me having to worry if I declared my tables properly.
Simply because it's been posted to other threads does not make it redundant, and simply because it bothers you that someone would point out flaws in MySQL does not make it flame bait.
It's also not a troll. Everything in that post is TRUE. While MySQL AB add functionality, they leave little broken parts all over in MySQL, and those parts need to be fixed. It's a reasonable complaint, and one that keeps me from recommending MySQL for most purposes. Sadly, the folks at MySQL haven't seemed real keen on fixing these issues due to backwards compatibility issues.
FYI, the Postgresql Global Development Group does something similar. They release 7.4beta1, 7.4beta2, 7.4beta3, then 7.4rc1, 7.4rc2, etc... Then, after release, they go to 7.4.1, 7.4.2, etc...
The added advantage is that they sort alphanumerically according to the order they were released in.
I'll see your SQL server and raise you one Postgresql server. We routinely kick MSSQL server's ass at work, by the way.
So how does innodb get around the example problem and still provide good parallel performance?
Postgresql doesn't have a high overhead for each row, it just uses up a bunch of space for things like write ahead logs and the default catalog.
I.e. a default install of 7.3.x will have a 7Meg base directory and a 16 Meg pg_xlog directory before any data has been added. So, while that's nothing to a modern computer with a gigabyte plus size hard drive, it's quite a large amount for an embedded device with a 128 Meg stick in it.
From that perspective, postgresql's data storage usage is friggin' huge.
Firebird is closer to Postgresql in capabilities, and closer to MySQL in terms of size (Postgresql is friggin huge, and sucks up disk space quickly, so it's a bad choice for embedded db applications with limited space unless you're willing to do a lot of hacking to make it "lose weight").
It felt a lot like postgresql to me. I didn't do anything fancy like writing a stored proc or a trigger or something like I've done in Postgresql.
So with the single transaction switch, is it guaranteed to be a coherent backup (i.e. all fk relationships should be clean and all that) or can you get a dirty read? Just wondering. Postgresql's hot backup literally runs in serializable mode, but since the back is read only, it doesn't actually lock anything.
Yep, I just recommended MySQL to a friend here at work, because it was the best fit for his project. It's a simple data delivery system, i.e. 99.99% static data with updates a few times a day at most. And it needed to run on a Windows Laptop. I also recommended firebird for the same project.
Sorry, but until MySQL has a mode where ALL tables are transaction safe, or at least throws an error when you try to create a fk reference to a non-transaction safe table, it's transactions are too prone to data loss due to human error.
It's a good data store, but the guys programming it have to "get it" that transactions can't be optional in certain types of databases, and neither can constraints, or fk enforcement.
MySQL has a tendency of failing to do what you thought it did, and failing to report an error so you know. This is a legacy left over from being a SQL interpreter over ISAM files. It makes MySQL a great choice for content management, but a dangerous choice for transactional systems.
Someone already did:
http://moulon.inra.fr/ruby/plruby.html
Oh wait, that's for Postgresql...
so is plphp, plperl, pltcl, plperl, plpgj (java), plR, plsh, and about ten or so more I can't remember right now.
FYI, the beta3 of plphp for postgresql is out, and after having tested it, it's pretty cool, and seems to work quite well.
OK, here's how it works. You take your logic for how data gets inserted, and you wrap it in a MySQL java function. You then restrict all update / insert access to said function, taking that ability away from users.
Now, timmy in accounting can program his Vic-20 to insert a payroll record, and no matter how goofy little timmy's BASIC program is, he can't screw up your data, because he doesn't have the power anymore. by restricting all updates to a single code path, you ensure the data cowboys don't go messing up your database.
And, you can then take your java functions with you to your next flavor of MySQL when you upgrade.
Horse puckies. Both Interbase/Firebird and Postgresql have had solid, reliable pls for many many years.
While JAVA stored procs are new to PostgreSQL, the lack of a specific language as a stored proc is pretty silly. PostgreSQL has solid reliable stored procedures in a dozen or so different languages, including perl, ruby, R, tcl, php, and C.
There areas where Oracle outshines Postgresql and MySQL, the are also areas which make it look bad in comparison. To think that the Open Source databases aren't competitive is to only look at one small segment (content storage databases like MySQL) and ignore the others, SAPDB (MySQL MAX??? stupid name, but a good database), Interbase / Firebird, and Postgresql.
I use Postgresql and prefer to it to MySQL, but this is neither the time nor the place to be such a pain in the arse. Do you really think the average MySQL user is gonna be converted like this? The Postgresql crowd is usually a bit more subtle than this. There are plenty of other issues why one might prefer one database over another, and neither MySQL nor Postgresql are the best or the worst for every job.
Correct me if I'm wrong, but doesn't that basically lock your whole database against writes during the backup? Just wondering.
Hehe, that's what having a windows port will do to your database I guess. Make you used to using spare machines all over the place. :-)
Note that the 3m microtouch screens can be ordered bonded right onto the front of a CRT. I had a project a long time ago where I had to create / program a kiosk, and all through the project my computer had a touchscreen, and I got so damned used to using my finger for a mouse that when I got rid of that machine I kept touching the screen to do things. :-)
One other thing they did was to put the top row 6 on the LEFT instead of the right. touch typists and most other ergo keyboards put it where it belongs, on the right. If they insist on putting a 6 on the left, why not put a duplicate one on the right where it belongs so touch typists aren't constantly cursing their shiny new MS keyboards.
I solved the problem by just bringing in my own damned keyboard from home at work.
Just remember, Sun has killed it before, and they can kill it again. Just use this simple formula:
p=m1-m2
where
p = profits
m1 = money to be made by abandoning X86 Solaris
m2 = money to be made by keeping X86 solaris
As soon as p is positive, Sun will cease production of X86 solaris again.
Sun has no loyalty to you, the user, so don't count on X86 Solaris to be there when you need it. We had a dozen or more X86 Solaris servers when Sun dropped it completely a while back, and had just finished converting most to Linux when they said "oops, sorry, we didn't mean to kill it" and brought it back.
Fool me once, shame on you...
Actually, my experience with older Ultra Sparcs (1, 2, etc...) is that they are MUCH faster under linux than under Solaris. About 50 to 150% faster at most stuff. This is especially true if they've got IDE drives in them, as Sun never really seemed to do a great job on the IDE drivers in Solaris (X86 or Sparc)
Postgresql runs about twice as fast on linux on sparc as Solaris on Sparc, for instance.
Just put that IP in as www.sco.com in your hosts table and voila, SCO is back up.
My guess is they were migrating servers and some weenie shut down the old one before propagating the DNS change.