Actually, I don't know of anyone in the Postgres community that looks down on SQLite. And most people don't look down on Access either, at least as a front-end.
The Feb 30 issue gets *even better*. For years I used that as a prime example of what's wrong with MySQL, so I was a bit disappointed when I found out they'd fixed it.
Then I discovered that Feb 35th is *STILL* a valid date! The only thing they fixed was Feb 30th and 31st!
That will sync the disks, but it won't stop the database from accepting incoming data. It won't stop cron jobs which might be just about to trigger. It won't deal with tasks that are in the middle of a big operation which involves a lot of writing to disk.
That's why you run an ACID database and not a toy database if you care about your data. If the database says "yes, it's committed" then the data damnwell better be committed (unless your hardware or OS is lying about when data hits non-volatile storage, in which case there's nothing the database can do).
MySQL requires code contributions to be re-assigned to MySQL AB, so AFAIK they actually own every last line of code. Which of course means that they are free to do anything they want, including close-source the whole thing.
MySQL hasn't been a project for a long time (if ever)... it's a commercial application that happens to also be GPL'd. The vast majority of the development is done by MySQL AB, and other than users there isn't really much of a community. I'm not saying this is wrong, but MySQL isn't a project.
FreeBSD provides a good (non-database to avoid the flamewar) counter-point. While there are some commercial contributors, there is absolutely no commercial control of the project. What control does exist does so in the context of a meritocracy.
There are plenty on benchmarks of MySQL vs. Postgres. The Postgres people seem to dispute these but they show MySQL killing Postgres.
Every single MySQL/PostgreSQL benchmark I've seen has either been absurdly trivial or benchmarked with MyISAM which is an apples to gorillas comparison. And they're all old benchmarks as well. Unlike MySQL's apparent philosophy of "1) Do the minimum to be able to claim we have feature XYZ 2) Make it fast 3) Maybe think about making sure it works sanely", the PostgreSQL community's top-most concern is data quality; performance is always seconday to that. Because of that there had been a lot of room for improvement through the 7.3/7.4 timeframe.
That's no longer the case. People commonly see 30%+ speed improvements from 7.4 to 8.0, and 2x that from 7.4 to 8.1. And more improvements are on the way. 8.2 is looking to have on-disk sorts that are 4x faster than today, as an example.
Actually, the PostgreSQL community is happy to point users at other databases, especially SQLite. They generally don't point folks to Firebird only because it's relatively recent on the OSS scene.
The community is reluctant to point users at MySQL however, because it's asking for trouble to do so unless the user already has a solid grasp of how databases should work and can therefor recognize all the shortcommings in MySQL and come up with work-arounds.
Some people want something that is very lightweight and fast.
In which case they should use something like SQLite, which unlike MySQL doesn't claim to be more than it is, has a better license and actually sticks with standards.
Actually, if you're going to use read-locking for ACIDity then row-level locking pretty much is mandatory unless you're completely read-only or single user.
Note that this has nothing to do with the row-level shared locks that PostgreSQL added.
Personally, I think MVCC is a far superior approach than read locking.
I don't think the post was about the cause or the result; it was about people ass-u-ming that this was a technical problem. His point is that it's not a technical problem, but a business (political) one.
The one technical side I wonder about is this: are there good enough tools to allow ISPs to act as transport between NSPs and be compensated (as in: not charged for that traffic)? That's the real reason why the internet of today is 'fragile' is because all the backbone traffic typically goes through a fairly limited number of points, not for technical reasons but for business reasons. If every multi-homed ISP also passed traffic between it's multiple providers the internet would be extremely well connected.
PostgreSQL is fine until you hit territory where it's not.
Given recent development history, it's going to be years before PostgreSQL has anything close to parallel query execution. And years more before it has clustering. And years more before it has the grid features that 10g has.
Of course with growing commercial interest that could all change very quickly. Linux used to be a toy compared to unixes, but millions (if not billions) of dollars worth of development from places like IBM completely changed that. But Oracle is the 800 pound gorilla of databases because they solved a lot of very hard problems. And I suspect they still have patents on a lot of that stuff, which could stand in the way of PostgreSQL and others.
Actually, there is quite a demand for people with PostgreSQL experience on their resume, and it's set to really explode with all the commercial companies pushing PostgreSQL. I don't keep exact track of recruiting emails I get, but it's been at least one a month for the past 12-18 months. Heck, I've had at least 2 if not 3 emails this month.
That's a good argument for procedures, but it doesn't require the stored part. I'd do that with a shared library full of C functions, a C++ class or a perl module.
That ass-u-me's that everything will always go through your app server, which is not always a given. IMO it limits you even more than putting code in the database, because now you can't ever use software that you can't make to work with your application layer.
I think you might be over-reacting a bit here. It obviously doesn't make sense to try and turn your database server into an application server (which is what your points seem to be arguing against). Even as much as I tend to have hammer-nail (when the only tool you have is a hammer, every problem starts to look like a nail) mentality when it comes to databases, I still would never suggest using your database server as an application server. It just doesn't make any sense.
On the flip-side, it does make sense for you database to ensure data integrity and correctness. For example, if you have a business rule that says 'no orders will be accepted if any item is out of stock', the database is the best place to enforce that because it's the only place that can truely enforce it. If you try and enforce it in your app server, you're screwed if anything else even has to talk to the database. And it's not like doing that kind of a check is going to put any real additional load on the database; most of the load will be in running the query to check stock levels.
Slashdot Mirror
Actually, I don't know of anyone in the Postgres community that looks down on SQLite. And most people don't look down on Access either, at least as a front-end.
Even better than 0000-00-00 is 2010-02-35.
The Feb 30 issue gets *even better*. For years I used that as a prime example of what's wrong with MySQL, so I was a bit disappointed when I found out they'd fixed it.
Then I discovered that Feb 35th is *STILL* a valid date! The only thing they fixed was Feb 30th and 31st!
MySQL clearly just doesn't get it.
You should have simply replied with "First UID". :P
As opposed to your high UID? ;P
That will sync the disks, but it won't stop the database from accepting incoming data. It won't stop cron jobs which might be just about to trigger. It won't deal with tasks that are in the middle of a big operation which involves a lot of writing to disk.
That's why you run an ACID database and not a toy database if you care about your data. If the database says "yes, it's committed" then the data damnwell better be committed (unless your hardware or OS is lying about when data hits non-volatile storage, in which case there's nothing the database can do).
MySQL requires code contributions to be re-assigned to MySQL AB, so AFAIK they actually own every last line of code. Which of course means that they are free to do anything they want, including close-source the whole thing.
MySQL hasn't been a project for a long time (if ever)... it's a commercial application that happens to also be GPL'd. The vast majority of the development is done by MySQL AB, and other than users there isn't really much of a community. I'm not saying this is wrong, but MySQL isn't a project.
FreeBSD provides a good (non-database to avoid the flamewar) counter-point. While there are some commercial contributors, there is absolutely no commercial control of the project. What control does exist does so in the context of a meritocracy.
http://www.linuxquestions.org/questions/showthread .php?p=2131445#post2131445 might shed some light.
And then of course there's http://sql-info.de/mysql/gotchas.html
There are plenty on benchmarks of MySQL vs. Postgres. The Postgres people seem to dispute these but they show MySQL killing Postgres.
Every single MySQL/PostgreSQL benchmark I've seen has either been absurdly trivial or benchmarked with MyISAM which is an apples to gorillas comparison. And they're all old benchmarks as well. Unlike MySQL's apparent philosophy of "1) Do the minimum to be able to claim we have feature XYZ 2) Make it fast 3) Maybe think about making sure it works sanely", the PostgreSQL community's top-most concern is data quality; performance is always seconday to that. Because of that there had been a lot of room for improvement through the 7.3/7.4 timeframe.
That's no longer the case. People commonly see 30%+ speed improvements from 7.4 to 8.0, and 2x that from 7.4 to 8.1. And more improvements are on the way. 8.2 is looking to have on-disk sorts that are 4x faster than today, as an example.
Actually, the PostgreSQL community is happy to point users at other databases, especially SQLite. They generally don't point folks to Firebird only because it's relatively recent on the OSS scene.
The community is reluctant to point users at MySQL however, because it's asking for trouble to do so unless the user already has a solid grasp of how databases should work and can therefor recognize all the shortcommings in MySQL and come up with work-arounds.
It's generally a safe assumption that PostgreSQL doesn't do things the way MySQL does, because MySQL generally does them wrong.
Here's a fun example:
CREATE TABLE t(t tinyint);
INSERT INTO t VALUES(300);
SELECT * FROM t;
What, you don't think 300 = 127?
Some people want something that is very lightweight and fast.
In which case they should use something like SQLite, which unlike MySQL doesn't claim to be more than it is, has a better license and actually sticks with standards.
The first smell of trouble from Oracle and they fork the last GPL version and take it from there.
And can't use it in their commercial product.
If they can't get their license for InnoDB renewed, their commercial sales are in big trouble.
Actually, if you're going to use read-locking for ACIDity then row-level locking pretty much is mandatory unless you're completely read-only or single user.
Note that this has nothing to do with the row-level shared locks that PostgreSQL added.
Personally, I think MVCC is a far superior approach than read locking.
MySQL is the WindowsME of databases.
I don't think the post was about the cause or the result; it was about people ass-u-ming that this was a technical problem. His point is that it's not a technical problem, but a business (political) one.
The one technical side I wonder about is this: are there good enough tools to allow ISPs to act as transport between NSPs and be compensated (as in: not charged for that traffic)? That's the real reason why the internet of today is 'fragile' is because all the backbone traffic typically goes through a fairly limited number of points, not for technical reasons but for business reasons. If every multi-homed ISP also passed traffic between it's multiple providers the internet would be extremely well connected.
PostgreSQL is fine until you hit territory where it's not.
Given recent development history, it's going to be years before PostgreSQL has anything close to parallel query execution. And years more before it has clustering. And years more before it has the grid features that 10g has.
Of course with growing commercial interest that could all change very quickly. Linux used to be a toy compared to unixes, but millions (if not billions) of dollars worth of development from places like IBM completely changed that. But Oracle is the 800 pound gorilla of databases because they solved a lot of very hard problems. And I suspect they still have patents on a lot of that stuff, which could stand in the way of PostgreSQL and others.
AFAIK the clustering and load balancing 'solution' for MySQL means your entire database has to fit in memory. Not very practical...
Actually, there is quite a demand for people with PostgreSQL experience on their resume, and it's set to really explode with all the commercial companies pushing PostgreSQL. I don't keep exact track of recruiting emails I get, but it's been at least one a month for the past 12-18 months. Heck, I've had at least 2 if not 3 emails this month.
Unlike MySQL, PostgreSQL has absolutely zero control over the distribution of their code, other than requiring the copyright notices.
If you're serious about your data, then try this out:
CREATE TABLE t(t tinyint);
INSERT INTO t VALUES(300);
SELECT * FROM t;
See also http://sql-info.de/mysql/gotchas.html
Clearly, it is a real database that is capable of doing real work.
I disagree. A real database wouldn't allow this:
CREATE TABLE t(t tinyint);
INSERT INTO t VALUES(300);
SELECT * FROM t;
You really meant 127 and not 300, right?
That's a good argument for procedures, but it doesn't require the stored part. I'd do that with a shared library full of C functions, a C++ class or a perl module.
That ass-u-me's that everything will always go through your app server, which is not always a given. IMO it limits you even more than putting code in the database, because now you can't ever use software that you can't make to work with your application layer.
I think you might be over-reacting a bit here. It obviously doesn't make sense to try and turn your database server into an application server (which is what your points seem to be arguing against). Even as much as I tend to have hammer-nail (when the only tool you have is a hammer, every problem starts to look like a nail) mentality when it comes to databases, I still would never suggest using your database server as an application server. It just doesn't make any sense.
On the flip-side, it does make sense for you database to ensure data integrity and correctness. For example, if you have a business rule that says 'no orders will be accepted if any item is out of stock', the database is the best place to enforce that because it's the only place that can truely enforce it. If you try and enforce it in your app server, you're screwed if anything else even has to talk to the database. And it's not like doing that kind of a check is going to put any real additional load on the database; most of the load will be in running the query to check stock levels.