Posted by
michael
on from the some-data-loss-inevitable dept.
ulrikp writes "Swedish MySQL AB, makers of the MySQL database, have released an Alpha-version of their flagship, dubbed MySQL 5.0.0. The changesinclude basic support for SQL-99 stored procedures. Please note: Despite the version number, this is an Alpha release, and not for general consumption."
273 comments
Windows-like version numbers
by
chill
·
· Score: 4, Interesting
This means that whenever it is stable and ready for production, it is going to have a random version number. Not the smartest practice.
It would help if the major stable releases were.0 and not.rnd()
-Charles
--
Learning HOW to think is more important than learning WHAT to think.
Re:Windows-like version numbers
by
Rosyna
·
· Score: 4, Informative
FWIW, MySQL AB has always used funky version numbers like this. 4.0.0 was alpha, looks like every release of 4.1 is alpha and 5.0.0 is alpha. 5.0.32 might be stable.
Re:Windows-like version numbers
by
Anonymous Coward
·
· Score: 3, Funny
Just avoid MySQL 5.0.0 and upgrade to MySQL XP when it comes out.
Re:Windows-like version numbers
by
Mr+Pippin
·
· Score: 1
Not unlike most commercial software. There tends to be a stigma that version 0 software is not ready for use (bug filled, missing key PROMISED functions, etc). Thus, many people wait until a.1 or such release before they will use it.
Just my experience
Re:Windows-like version numbers
by
chill
·
· Score: 4, Informative
MySQL may be many things, but "slow as hell" has NEVER been a complaint. It is many times faster than other SQL servers -- mainly because of the lack of other features.
MySQL has often been described as more of an SQL-interface to a file system than a database.
--
Learning HOW to think is more important than learning WHAT to think.
Re:Windows-like version numbers
by
khuber
·
· Score: 0, Flamebait
Where do I download the Microsft SQL Server for Linux?
Re:Windows-like version numbers
by
Sxooter
·
· Score: 2, Informative
I'll see your SQL server and raise you one Postgresql server. We routinely kick MSSQL server's ass at work, by the way.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:Windows-like version numbers
by
sketerpot
·
· Score: 1
Yes, that and the Microsoft bit make me think that the grandparent post was just trolling.
Another reason that MySQL is so fast is because of its query caching.
Re:Windows-like version numbers
by
BrynM
·
· Score: 2, Insightful
The troll probably has installed MySQL under Win32 on a badly fragmented NTFS partition. I can attest first hand that it will kill performance for MySQL. NTFS performance degrades badly when highly fragmented, I don't care how good the drive hardware is. Kepp a good defrag too handy if you are running under Win32 and have files that grow.
-- US Democracy:The best person for the job (among These pre-selected choices...)
Re:Windows-like version numbers
by
Anonymous Coward
·
· Score: 0
Diskeeper actually increases the fragmentation on my drive in Windows 2000, but for some reason the built in defragmenter (also by Diskeeper) actually works and reduces the fragmentation. I don't get it.
Re:Windows-like version numbers
by
jadavis
·
· Score: 1
MySQL may be fast under some circumstances, but come on... "many times faster than other SQL servers" is an exaggeration. Do you have any actual numbers to back that up? Or are you just assuming that it's fast because of its lack of features?
-- Social scientists are inspired by theories; scientists are humbled by facts.
Re:Windows-like version numbers
by
BrynM
·
· Score: 1
The stored procedures are not real either, just check this link on MySQL's own site!
Re:Very nice
by
Anonymous Coward
·
· Score: 1, Informative
To name just one: PostgreSQL is free and contains subquries and stored procedures (and much much more). Also it has been using a much more professional approach than MySQL (which has oddities like allowing 2004-02-31 to be stored in a date field)
Re:Very nice
by
sketerpot
·
· Score: 3, Informative
Remember that PostgreSQL is also free, and has a number of very cool features. I'm not telling you which one to use, but do remember that MySQL isn't the first open source database to have those features, nor the only one.
Keep on waiting. These are not real subqueries. Stuff such as SELECT name FROM TABLE_1 WHERE id IN (SELECT eligible FROM TABLE_2) still does not work.
That's been working for years on PostgreSQL. I just tried it again to be sure. PostgreSQL even outpaces MS's SQLServer.
drop table xfoo_a;
create table xfoo_a
(
a int
);
drop table xfoo_b;
create table xfoo_b
(
b int,
x text
);
insert into xfoo_a ( a ) values( 1 );
insert into xfoo_a ( a ) values( 2 );
insert into xfoo_a ( a ) values( 3 );
insert into xfoo_b ( b, x ) values( 1, 'One' );
insert into xfoo_b ( b, x ) values( 7, 'Seven' );
insert into xfoo_b ( b, x ) values( 3, 'Three' );
select x from xfoo_b where b in ( select a from xfoo_a );
I still don't know why MySQL has such a following when somthing like PostgreSQL is so much better in virtually all respects (IMHO that is).
Re:Very nice
by
Anonymous Coward
·
· Score: 0
Marketing.
Re:Very nice
by
Anonymous Coward
·
· Score: 1, Informative
Keep on waiting. These are not real subqueries. Stuff such as SELECT name FROM TABLE_1 WHERE id IN (SELECT eligible FROM TABLE_2) still does not work.
Subqueries, including ones exactly like that, have worked on MySQL since 4.1.0. I even just tested it.
In my opinion, PostgreSQL is the superior database. Many of the features that are "alpha" in MySQL have been in PostgreSQL for years and are very mature. Using MySQL, there are features that I miss that are present in PostgreSQL. I haven't noticed the reverse at all.
However, there are a couple of very good reasons to use MySQL:
Windows support is much better with MySQL than PostgreSQL.
Far more hosting companies support MySQL than PostgreSQL
Personally, I couldn't care less about Windows support, but writing apps for clients that want to host their stuff on an inexpensive shared account makes MySQL the obvious target of choice.
Keep on waiting. These are not real subqueries. Stuff such as SELECT name FROM TABLE_1 WHERE id IN (SELECT eligible FROM TABLE_2) still does not work.
Many subqueries like that can be solved using left joins
Correlated subqueries are nothing compared to derived tables:
Select foo from ( select bar as foo from baz ) as derived_foo where...
It's a highly useful technique that often lets you avoid having to create a view or temp table.
-- Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
Not that uncommon
by
Anonymous Coward
·
· Score: 1, Insightful
The Apache 2.0.x series has seemed similar. They weren't production ready until the 2.x.3?'s.
Re:Not that uncommon
by
Kent+Recal
·
· Score: 0, Offtopic
Production ready, apache 2.*? Give it some more years...
Re:Not that uncommon
by
AntiOrganic
·
· Score: 2, Funny
If it's good enough for kernel.org it's good enough for me.
I'm not saying apache 2.0.X isn't stable or anything but how many hits does kernel.org get? Now if you had said CNN.com or some other major component of yahoo then I would agree with you.
--
----- One is born into aristocracy, but mediocrity can only be achieved through hard work.
The problem with Apache 2.x is not the quality of it, per se, but of third party modules. Officialy PHP is unsupported with 2.x (though LOTs of sites use it, trouble free). I dont think mod_perl is either.. And even if perl does work, there are a lot of additional perl modules that arent quite upto date.
Re:Not that uncommon
by
Anonymous Coward
·
· Score: 0
weeeh!!! I love my Mother.... Daddy abandon you?
Re:Not that uncommon
by
Anonymous Coward
·
· Score: 0
Looking over your past few posts... you seem to have gotten very angry around Christmas.... Does saden come from a broken home? Where's Daddy??
saden is very sad.
Re:Not that uncommon
by
Anonymous Coward
·
· Score: 0
There are webservers written in pure Java that take that kind of load:) When it starts handling thousands of hits per second, then that's getting close. The CNN webfarm can handle 100x's that load when its spun up. When sharing load with AOL - who knows what the total serving capacity is.
Yes, Apache 2.x release was 2.0.32 I believe. Apache, like MySQL, use the major verion number to indicate large changes which may not be backwards safe.
5.0 is saying be aware when upgrading from 4.0 - it's clearer than the same changes being numbered 4.1 and 4.2, which lead one to believe it's just an update.
As a side note, I'm surprised they went to 5, given the todo list they put out for 4 isn't complete and inface the features of 5 were on that list for 4.
Have they fixed the most serious bug from the 4.x line yet? This makes MySQL versions greater than 3.x utterly useless for many people.
I realize and reaffirm that it is wholly their right to license their software however they like, but would it really be so awful for them to make the client library LGPL?
*sigh* i never seem to have mod points for the flamebaits when i need them ):
Re:Serious bug
by
Anonymous Coward
·
· Score: 0
Perhaps you get so little of them, because you abuse it. If you want to avoid meta-moderation, you have to use "overrated" when you try to punish heralds of unpopular truths.
Re:Serious bug
by
neverkevin
·
· Score: 2, Insightful
Maybe you sould have made it clear in your post that it was "sarcastically funny, but honest criticism" instead of making it look like flamebait and tring to explain it is not after the fact. Bitching about how you got modded is lame.
The problem is that a lot of otherweise nice stuff (like this) or this makes use of MySQL and nothing else. No Postgres, no Oracle.
Is there a way around this type of mess? A good CMS that will work with Postgres?
i am not much of a database expert, but i have used transactions, rollbacks (and commits:) as well as subselects with MySQL 4.1, so please enlighten me: what makes these feature not "proper" in MySQL?
Grandparent is a DB-fascist who doesn't think that programmers/admins are able to decide for themselves whether those features are needed in their particular application and thus should be required to use them in all cases.
AFAIC, MySQL's support of a diverse range of table types with differing feature profiles is one of the greatest features MySQL has.
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.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
True. If you don't need multi-statement transactions or whatever don't use 'em.
But why are differing table types an advantage? PostgreSQL only has one table type, and I don't notice anything missing from it. I am still waiting for a MySQL advocate to come up with some feature that makes it somehow more useful than PostgreSQL. PostgreSQL guarantees the enforcement of all of your rules (i.e. foreign key, all types of constraints, etc), database wide, no matter what. MySQL people argue all day about why they don't need the enforced consistancy in postgresql, but I haven't heard anyone say that postgresql doesn't suit their needs for reasons X, Y, and Z.
I really would like to know of some features, I'm not just being argumentative.
-- Social scientists are inspired by theories; scientists are humbled by facts.
I use Oracle and Postgres in a lot of projects, and I hate that I can't use MySQL without rewriting a LOT of code because it does not support sequences...:(
What I've heard is MySQL's main point in favor (at least on the MyISAM table) is the performance, especially on a command sequence that largely consists of SELECTs, with comparatively few write ops. It is probably reasonable to suspect that at least some of that performance advantage over (as near as I can tell) every other SQL (or near-SQL) implementation comes from not implementing the extraneous stuff.
Thus, if you have an application where the queries are going to mostly be SELECTs (and the application effectively does its own constraint checking and approximation of foreign keys), MySQL with MyISAM is almost certainly the best choice, as you don't need to use the extra features that others provide, and the performance increase is useful.
Does this mean that MySQL/MyISAM is ideal for any other type of application? No. Is it even suitable for any other application? Absolutely not, and anyone who says otherwise is probably insane.
But there's a large application space where the constraints and query sets are well-suited for MySQL/MyISAM (web CMS type things being but one example of this... basically anything that just needs a datastore that's reasonably relational where an SQL-like interface is useful).
Boxing day, eh? Any news on the Beagle? Next potential for communications is suppose to be on boxing day... Let those who are still on Christmas know so we won't have to wait!
Well, seeing as MySQL AB is a Swedish company, and we scandinavians celebrate December 24th as the "main day" of xmas, it isn't that bad. Non-christian scandinavians don't care about December 25th.
And who is reading f$%king slashdot on Christmas Day too??
I keep waiting for them to put a story about it being Xmas day on the front page so I can watch everyone say it's a dupe ('they posted this last year...'); I'm sure I'm not the only one.
Who the hell is coding and releasing new versions on Christmas Day? Take a break!!
If you look at the current poll, it appears that 10% of Slashdotters will be coding...
-- my sig's at the bottom of the page.
Re:eh?
by
Anonymous Coward
·
· Score: 0
However, it is a red day in your non-christian calendar too.
MySQL hires people from around the world, and not everyone celebrates Christmas (though for the company it is a holiday). Several people showed up to our scrum meeting this morning and I have spent the last couple of hours talking about a few slight changes to our protocol this morning.
Personally I will later on be celebrating the day by watching Return of the King:)
Don't you geeks celebrate Christmas? My God.. can't slashdot just not post stories during the Holidays so then I don't have to visit so often
Most of the world does not celebrate Christmas, so why do you find it so amazing that people may be reading Slashdot on December 25th? Hell, I celebrate Christmas and am reading Slashdot because I don't feel like dealing with family.
In addition, I've now time to lessen the crushing workload I've buried myself under. I'll take a moment tonight to celebrate, but for now, I'm working away:)
Keep in mind that a good part of the Southern Hemisphere is out combing the boxing day specials while our northern hemisphere cousins are sitting down to their Xmas meal.
Same for new years. Always somewhat amusing to watch on the TV live coverage of the New Years Ball drop in New York when say, New Zealanders have had New Years coutdown some 24 hours previous.
--
In post Patriot Act America, the library books scan you.
I have to confess..
by
wackybrit
·
· Score: 3, Interesting
I've been using MySQL 4.1 on a live server (with customers) for two or three months now. I basically wanted subqueries at the time, and so I just upgraded the box with disregard for everyone else;-) Luckily everything worked great! There's a little quirk with Unicode if you play with the character type settings on certain fields (as long as you stay away from Unicode you'll be more than okay). I also occasionally have the server die when given certain lengthy queries, but it comes straight back, and gets on with things.
So, no, it's hardly Oracle, but even MySQL's alpha stuff seems to be reasonably usable, as long as you aren't doing anything too serious. And, as any database expert will tell you, you probably aren't going to be using MySQL for anything that serious anyway. Nice work MySQL.. I'll spare my users from an immediate upgrade to MySQL 5 however.. for now!!
It's hardly a big deal, MySQL's data storage method is separate enough from the server that if it fried, I could have had it back on a stable MySQL within a couple of minutes. And considering I did it at 3am on a server that serves less than 10GB a month, no biggie;-)
You might be a database expert, but some of us are better at server administration and recovery than you might think;-)
Maybe I'm just old school but the whole idea of making even more variables case insensitive is for me just complicating the syntax even more
And even though we're all trying to make our programming languages more "human like" I don't think that the base ideas of programming have reached the point where those steps should be giving that kind of attention.
Indeed, Stored Procedures Will Be Nice
by
Saeed+al-Sahaf
·
· Score: 0
This story will of course bring out all the PostgreSQL trolls, But really, there are very few trolls against MySQL that hold much water, anymore. The response to this post (if there are any) will go like this: A bulleted list of general gripes with nothing to back them up. Funny thing is, these trolls are quite willing to pass off on the faults of their favorite dB by downplaying the importance of a particular lacked feature, or that some shortcoming really doesn't have much effect in "real-world" use. Like many fine products, MySQL does not try to be all things to all people, unlike the code-bloat MS-SQL and Oracle.
-- "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Re:Indeed, Stored Procedures Will Be Nice
by
Anonymous Coward
·
· Score: 0
according to your own definition you're a troll as well; though not a bulleted list you have nothing to back up your claims - you don't even claim anything except people liking postgresql are trolls.
Re:Indeed, Stored Procedures Will Be Nice
by
Tukla
·
· Score: 1
these trolls are quite willing to pass off on the faults of their favorite dB by downplaying the importance of a particular lacked feature
Yes, like this comment from ryen: "Many subqueries like that can be solved using left joins"
Oh, wait! He was defending MySQL's lack of subselects. Does that make him a MySQL troll?
Re:The big question:
by
Anonymous Coward
·
· Score: 0
Mensa member, beware of the high IQ
It's so kind of you to hide that fact in the body of your message. Just kidding.
MySQL is still a database that is growing up. It is of course rock solid and fast (and good for some purpose), but it is missing some of the so called "enterprise" features ("real" replication, performant stored procedures, support from all the enterprise tools ("hot" backup solutions, etc))
It is quite interesting what they are doing with MySQL-Max with seems to be their enterprise solution. They teamed up with SAP DB, an open source database technology that SAP bought from Software AG to tease Oracle a bit. It is based on Adabas D a commercial database that has a "oracle compatibly mode" via ODBC.
It is quite interesting to see a mixture of SAP DB and MySQL united in MySQL-MAX. (Infoworld article)
Re:MySQL, MySQL-Max, Enterprise RDBMS
by
Baki
·
· Score: 1
Mainly it is missing support for normal SQL (92). They may be talking about "ansi 99 stored procedures", but what's the use as long as essential features in SQL (ansi 92) such as subqueries are still not supported, and as long as transactions are still an add on and not standard?
Adding features before "growing up" is not a good sign. I don't call adding features before essential functionality growing up.
Re:MySQL, MySQL-Max, Enterprise RDBMS
by
ceeam
·
· Score: 1
I know _you_ don't imply it but it's funny like all the people are complaining about lack of _enterprise_ features in DBMS Xxxx... Like all the DBs on earth are enterprise level. You know what? There are _tons_ of RDBMS applications besides bean-counting. And most _enterprise_ class RDBMS won't fit _there_.
Re:MySQL, MySQL-Max, Enterprise RDBMS
by
abirdman
·
· Score: 1
Amen. Thanks for pointing that out.
The PostgreSQL vs MySQL debate always seems to hinge on features, but rarely on adequacy to the task at hand. A good programmer can knock together a data-centric application that has great data integrity and works as required using.TXT files! When it comes to "enterprise" class, though, the implication is that there is a division of labor between the front-end program(s) that is the "source" of the data and the database itself.
In the first case, where the data is completely managed by one front-end (viz many of the small to medium web applications out there), what's needed is a small, fast, simple database backend that will store and retrieve data quickly and reliably. The programmer (or small team) controls the tricky issues, like integrity, consistency, concurrency, etc., all in the program.
In the second case, where there's a different person/team responsible for the database per se, or more than one set of programs uses the data, then the advanced features like triggers, views, stored procedures, sub-selects, become more important. DBA's don't (many can't) read code. A team of programmers writing a new front-end (or a totally new application) that accesses the data can't be expected to replicate all of the integrity/validation/transaction processing logic from another application into the new system. They can use advanced database features (like triggers, foreign key integrity constraints, etc.) to apply rules and consistency checks outside of the front end programs that are actually collecting/manipulating the data. This ability to control the data independently of any front end program is a great feature. It is, however, completely overkill for many day-to-day tasks.
Take it from someone whose been writing data-centric front-ends for "databases" from dBase II to Oracle every day for the last 15+ years. It doesn't take a huge database server to make an effective application. And not every application requires the ability of a DBA to enforce rules from outside of the application itself. Maybe a simple rule of thumb is "the more people working on the data, the more complex the DBMS that's required." PostgreSQL is a great product, but if it's used without the stored procedures (well, functions), integrity constraints, and triggers, I don't see it as any improvement over MySQL (which I believe, on strictly limited and anecdotal evidence, to be slightly faster).
-- Everything I've ever learned the hard way was based on a statistically invalid sample.
Re:great, now all we need is...
by
Anonymous Coward
·
· Score: 0
MySQL supports full text indexing and search as well. And I bet it's much faster than PostgreSQL's.
Maybe since it's Christmas day we can't expect people to read the manual.
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using. MySQL 4.x has replciation between master adn slave databases. Using replication you can easily do backups without taking down your live server. MySQL 4.1.1 Does subqueries. MySQL 5 should be where we get database clustering.
Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
How about foreign keys? I looked in the manual and STILL didn't see that.
Re:About MySQL
by
Anonymous Coward
·
· Score: 0
Yes because only kids would ever want something like support for foreign keys. I'll be sticking with real databases thanks.
Re:About MySQL
by
Anonymous Coward
·
· Score: 0
If it's not production it's NOT available. kthnx
Re:About MySQL
by
Anonymous Coward
·
· Score: 0
What about views? How about triggers?
I just took an Information Systems class. We had to create a database, but MySQL lacked about half of what was taught in the class. Weak sauce.
Re:About MySQL
by
IANAAC
·
· Score: 4, Informative
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using.
The reason people continue to say there's no tranaction support is probably because ANY other database out there does not require you to explicitly specify what type of table is needed to actually get transaction support.
I'll get modded as a troll on this one, but honestly, MySQL seems to do things opposite any other DB. The things you mention which are doable (transactions, subqueries) require significant rewrites to port an app to or from MySQL.
Re:About MySQL
by
Anonymous Coward
·
· Score: 0
you found one thing!
For anyone serious about databases that one thing is a complete show stopper. There isn't any need to look for anything else.
> Using replication you can easily do backups without taking down your live server.
> Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
You bet - so when are they going to support a free online backup solution that isn't a complete hack?
I mean really - backing up your replication server? That's a pathetic solution...
Re:About MySQL
by
Anonymous Coward
·
· Score: 0
Do you try to eat soup with a fork? If you need these features, use something else.
Re:About MySQL
by
leviramsey
·
· Score: 2, Informative
There is an overhead to transactions and not every application requires transactions (for instance, a web board). Thus, having the flexibility to use transactions for some tables and not for others is actually a good thing. Use the right tool for the job.
Now if only InnoDB supported all the features of MyISAM...
MySQL 4.1.0 also does subqueries and that is the reason I installed it. I shouldn't have. 4.1.0 worked fine on my old server, but when I moved to a new one it decided randomly deny users all the time. When 4.1.1 came out I decided to try to upgrade and see if my problem has been fixed, but the the encrypted password format was changed and I had to reset the passwords. That would be fine except the tool that does this doesn't work since MySQL 4.1.1 can't find any databases at all.
Re:About MySQL
by
Anonymous Coward
·
· Score: 0
Most "web boards" could use transactions in several places. Just because they don't, doesn't mean they aren't needed.
Forum software, by and large, is not top quality software.
The things you mention which are doable (transactions, subqueries) require significant rewrites to port an app to or from MySQL.
The only thing you need to do is change a line in the config file and specify the table type when creating the tables. I don't call that a significant rewrite to be honest. A simple search and replace would do it.
I got bit once by the table type changing back to the default during an ALTER. I don't know if it has been fixed, but beware something like ALTER TABLE DROP COLUMN removing transaction support for those tables.
Also remember transactions silently fail! You need to quadrouple check everything first since you cannot rely on the database to tell you something is wrong.
I simply cannot trust myself to use MySQL for important data. Too many things to double and triple check are *still* correct and properly constrained.
The "significant rewrite" I was referring to is regading (as I said in my original post) transactions and subqueries. I'll say it again, for the upmteenth time: MySQL does NOT conform to SQL standards. As a result, pretty much anything you've written on any other database will not work on MySQL without a rewrite. I'm talking about standard SQL that goes a bit beyond simple SELECT and UPDATE statements. I'm talking about date munging, varchar/char screw-ups, truncated unions, silly concatenation, etc. All of these things are standardized and taken for granted (as they should be) in any other database.
I'm happy that you can do everything you need to do with MySQL, but please... don't pretend that it's drop-in compatible or trivial port your code from one DB to another.
Re:The big question:
by
Anonymous Coward
·
· Score: 2, Funny
hahahahahhaha
mssql
hahhahahahahahahaha
o man, good one!
Re:why this matters?
by
Anonymous Coward
·
· Score: 0
Perhaps the people using MySQL don't use those features you mention. Maybe they need to run a native Windows (not Cygwin) version or another platform that isn't supported by PostgreSQL. Could be they have some app they want to use that comes out of the box setup to use MySQL.
I use them both, and I won't say I don't think Postgres is better, but there are times when MySQL works just as well.
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether.., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
--
make install -not war
Re:alpha, beta, release versions
by
bobintetley
·
· Score: 1
Wow, I used to work for a guy that really hammered that into me...
Andy, is that you?:-)
Re:alpha, beta, release versions
by
Doc+Ruby
·
· Score: 1
I am not now, nor have I ever been, "Andy":). But that's the thing about discipline: the same thing, over and over. And it works.
--
--
make install -not war
Re:alpha, beta, release versions
by
Snebjorn
·
· Score: 1
This is by far the best set of rules about release nomenclature I've ever seen - can I keep it?/Snebjorn
-- Faster-Harder-Louder
Re:alpha, beta, release versions
by
Doc+Ruby
·
· Score: 1
Thank you very much - your response was one of the best reasons I've ever had to post to Slashdot:). Please appreciate the nomenclature by spreading the technique.
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.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:alpha, beta, release versions
by
Doc+Ruby
·
· Score: 1
I think it's funny that some devteams release a series of betas, *and* release a series of "release candidates". Is the extra "RC" round a series that merely tests the packaging and distribution, with all other code frozen?
--
--
make install -not war
Re:alpha, beta, release versions
by
Sxooter
·
· Score: 1
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.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:alpha, beta, release versions
by
Doc+Ruby
·
· Score: 1
I wonder if interteam communications are sophisticated and clear enough to actually have separate versions for each interop factor. That is, a given software version would have a version for each of its GUI, features, API, and data formats. With major=incompatible, minor=compatible, and build/patchlevel. Like 3.1.1:2.5:4.2.2:2.2, or G3.1.1:F2.5.4:A:2.2. With merely incremental numbers, like v1, v3, v15, as the release numbers. Probably too complicated.
Why would you want to keep version numbers lower when you make better and more advanced software the higher your version number is in the minds of so many consumers?
MySQL Suitability for,,, stuff.
by
NeGz
·
· Score: 2, Insightful
I've just skimmed over the comments, and seen that a few people mention that MySQL is not yet ready for use on a critical server in the real world.
Now, I'm no database expert at all, and I've only ever used MySQL for databases. But as far as I know, slashdot itself runs on MySQL (supporting evidence?). Now, this is a site that gets a hojillion comments per article, several articles per day, with enough viewers to crush lesser sites at will. Surely this suggests that MySQL must be ready for "mission critical" use, at least in some circumstances.
slashdot needs to use page-level caching even though it handles only 3 requests per second. You could do far better with other technologies.
Re:MySQL Suitability for,,, stuff.
by
pyite
·
· Score: 1
No, no it doesn't. Slashdot is NOT mission critical, far from it in fact. If Slashdot loses an article and associated comments, who the hell cares? See comments above for why MySQL is not Enterprise and/or useful for mission critical applications (lack of transactions, lack of relational integrity, etc).
--
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
Re:MySQL Suitability for,,, stuff.
by
grmb1
·
· Score: 1
MySQL is good for simle CMS apps, one of which Slashdot is. However, data loss or broken DB integrity won't harm Slashdot too much.
Now imagine financial/banking database application wich process monetary transactions - in case of any serious data or integrity loss DBA and developers likely will get shot.:) Damages can count there for million dollars.
'Mission critical' means for DB not just TPS (transactions-per-second) numbers. Data safety is usually more important than speed.
--
--
grmbl woz heer
Re:MySQL Suitability for,,, stuff.
by
Sxooter
·
· Score: 1
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.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:MySQL Suitability for,,, stuff.
by
KyleCordes
·
· Score: 1
My experience is that every application is mission critical to the company that owns it. They wouldn't be paying me to work on it if it wasn't data they want to not lose.
I personally wouldn't be upset if Slashdot lost a few comments here and there, but I'd guess that the folks who run slashdot.org take data loss pretty seriously.
Re:MySQL Suitability for,,, stuff.
by
Inthewire
·
· Score: 1
Re:great, now all we need is...
by
Anonymous Coward
·
· Score: 0
Wow.
I mean, wow.
From that comparison, I'll switch my shop from a fully functional PostgreSQL installation to MySQL. For reference, I'll point to post #7808905 on slashdot. Save some money instead of hiring a consultant.
Perhaps the people using MySQL don't use those features you mention.
You can do a lot of stuff in MySQL by working around missing features. But WHY???? There are free alternatives out there that don't have key missing features, and don't force you to write these work arounds.
Excuse me ...
by
bitsformoney
·
· Score: 0, Flamebait
wasn't there a post the other day saying hello, this is the 21st century, we need no databases anymore?
Slashdotters get so excited over an improvement in any technology, they'd drool over an improvement of the steam engine.
-- This comment is printed on 100% recycled electrons.
Re:Excuse me ...
by
Anonymous Coward
·
· Score: 0
Well, a nuclear powerstation is really just a souped up steam engine with a generator tacked on the back.
Now....
by
Anonymous Coward
·
· Score: 0
Now I know your IP bitch. You'll never been safe now. Get ready for the pumpkin!
Re:MySQL and PHP legalities
by
Anonymous Coward
·
· Score: 1, Insightful
The problem is that the licences don't allow you to distribute MySQL and a MySQL-enabled PHP together, hence for example Red Hat is still including MySQL 3.x with their newer offerings like Fedora.
There is however no problem with you downloading MySQL from mysql.com and PHP from php.net, configuring php to use your local MySQL copy and then running the two together. At least for Linux users this is no problem, since it's literally a 3 minute operation. It's on Windows it gets ugly when you have to recompile PHP, how many windows users have (or want) a compiler around?
Re:MySQL and PHP legalities
by
Anonymous Coward
·
· Score: 0
this is so far wrong it is laughable.
PHP "used" to compile/distribute automatically with MySQL support installed by default. That means the libraries would be embedded into distributed binaries.
All PHP had to do was remove the "default" libraries, yet still leave MySQL installation as an option (--with-mysql=/path/to/mysql), and there are no licensing issues.
MySQL is now GPL, so you cannot include MySQL code (embedded db) in a product without continuing the GPL.
Also, the PHP group was trying to work this out with MySQL prior to the PHP 5 beta releases, so that PHP users would still have MySQL by default.
- only AC because my acct. doesn't work. - httpdotcom (m. geier)
And it is not as slow as postgres either. I love postgres, I love the features but the performance under heavy loads plainly sucks.
--
Got Code?
Re:Unlike PostgreSQL
by
Anonymous Coward
·
· Score: 1, Informative
"but the performance under heavy loads plainly sucks."
What are you talking about? PostgreSQL shines under heavy loads and large databases. It's MySQL who chokes on heavy loads and large databases.
Get a clue.
Enterprise-readiness questions
by
Wolfier
·
· Score: 1
Can a single table hold at least 100GB of data, and still have fast read-write access, say, less than 30ms for both a SELECT with index and INSERT?
How much time does it take to do a backup of a 100GB database?
Failover support: when a slave takes over, how long does it take to restore the master and switch back for a 100GB database?
Are views or foreign keys with constraints supported?
Does stored procedure increase performance by precompilation?
Re:Enterprise-readiness questions
by
Anonymous Coward
·
· Score: 0
What percent of applications in the world need the features you are questioning? 2%? Less? Just because it lacks a few features for some applications doesn't mean that it isn't a great database for a great many other applications.
Re:Enterprise-readiness questions
by
altamira
·
· Score: 1
You're right, but - that was not what the poster said. Instead, he questioned the proclaimed readiness for the enterprise market.
Re:MySQL sucks
by
Anonymous Coward
·
· Score: 0
Welcome to Slashdot. Say anything bad about Linux, MySQL, etc and you'll be modded as a troll. On the flip side, say anything good about BSD, Microsoft, etc and you'll be modded as a troll.
Re:MySQL and PHP legalities
by
realcheese
·
· Score: 5, Informative
How did this get modded up so high? This has been hashed over before and it's not illegal to use them together.
See the PHP FAQ
Another relase from the RDMS that told us transactions weren't important and would just slow things down.
-- Martin Brooks / Slayer99 #linux / UIN 2178117
MySql vs. Postgres
by
Alien_Phreak
·
· Score: 4, Interesting
Hi all,
I keep hearing about all the great god-like features of Postgres....but what exactly can Postgres do that mysql can't? i'm going towards setting up a central database (MySQL) linux server at work which will be accessible via Ms. Access using an ODBC driver from the clients. (ie. client running Msft Access changes data on a mysql database on a linux server, easy enough to use gui and a strong enough backend)
So far, i'm not doing anything out of the ordinary. nothing too complicated database wise. What exactly would be the advantage of using Postgres.
What does it do that mysql can't?
Re:MySql vs. Postgres
by
Anonymous Coward
·
· Score: 0
Its more along the lines of, if you don't know what your missing, you don't need it. If you are setting up a basic DB for whatever, you will prolly not need stored procedures, transactions and what not.
What is MySQL missing that PostgreSQL has ? Its far too long to list.
I keep hearing about all the great god-like features of Postgres....but what exactly can Postgres do that mysql can't? i'm going towards setting up a central database (MySQL) linux server at work which will be accessible via Ms. Access using an ODBC driver from the clients. (ie. client running Msft Access changes data on a mysql database on a linux server, easy enough to use gui and a strong enough backend)
Not to put you down, but if you don't understand the differences between the two (or any other database for that matter) you shouldn't be setting up any kind of client/server database system. Really.
It's because of this "I'll just throw up a database system" that makes systems unusable. It's not trivial stuff.
Sorry for the Scrooge Bah-humbug.
Re:MySql vs. Postgres
by
kpharmer
·
· Score: 1, Troll
> So far, i'm not doing anything out of the ordinary. nothing too complicated database wise. > What exactly would be the advantage of using Postgres.
How's this - you'll be using a mature database that has a good implementation of almost all standard database functionality - vs one that has only implemented some of it, and has repeatedly claimed that this standard functionality wasn't necessary.
So, now MySQL is quickly trying to check off all these deficiencies, which include:
- transactions
- unions
- subselects
- triggers
- views
- stored procedures
- stored procedures
- parallelism
- online backups
- replication
- clustering
- etc Some of these have been partially implemented in the 4.1 release, some are now being addressed in this new alpha. Most exist today in postgresql - and are now being incrementally improved.
Who knows? Perhaps they'll do a competant job - on the other hand functionality like 'subselects' isn't something you simply 'check off'. You want a carefully-designed implementation that covers much of the functionality implied here - not just a minimal job.
Not to say that mysql can't do a fabulous job at improving their product in record time. However, I see no reason to give the same company that insisted this functionality wasn't necessary the benefit of the doubt here. Especially when their current stable product has so many unacceptable silent failure modes.
which will be accessible via Ms. Access using an ODBC driver from the clients.
Not answering your question here or anything, but you might want to check out Rekall if that Access code is not in place yet.
-- Save your wrists today - switch to Dvorak
Re:MySql vs. Postgres
by
Anonymous Coward
·
· Score: 0
Oops, one of your list items (stored procedures) got inadvertently replicated. Or there's a dupe in your MISSING_FEATURES table.
Sorry... I'm just having fun.
We have a postgreSQL system (well, cluster) that handles 400-800 queries/second sustained for several hours a day (it's a stock-market information system).
We tried MySQL and decided against it because:
a) It was much, much slower with a large number of concurrent queries. b) It has really, really bad error reporting - it just silently truncates, converts and discards data. c) Their implementations of foreign indices is somewhat flawed, and there are no stored procedure or triggers.
(b) was the killer - it's really painful to have to do all your data integrity checking yourself rather than letting the DB do it.
Discussion of MySQL should include MySQL gotchas:
by
Futurepower(R)
·
· Score: 0, Redundant
Any discussion of MySQL should include MySQL gotchas:
Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.
Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.
# Important Stuff: Please try to keep posts on topic.
# Try to reply to other people's comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
# Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust
> But WHY???? There are free alternatives out there that don't have key missing features, and don't force you to write these work arounds.
nostalgia? I mean, there are some folks who really miss that 70s pre-RDBMS coding in IMS, ISAM, etc....
Things broken with MySQL
by
jesterzog
·
· Score: 4, Interesting
One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas for starters.
The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.
On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.
So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.
In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.
MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.
Re:Things broken with MySQL
by
Anonymous Coward
·
· Score: 0
MySQL and any other SQL is painful to code versus a great 4gl db language like Progress.
Perhaps the PHP guys can work together better with the MySQL folks to make coding as easy as 4gl.
I know some of you never heard of Progress webspeed, but I bet I can create an web app faster with embedded 4gl on webspeed versus coding PHP with SQL, C# or java (especially java)
MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details.
That seems to be the general gist. But my pet peeves are that people (journalists even!) that claim that 1) MySQL is the only/best Open Source RDBMS, or even worse 2) MySQL is comparable to the big commercial RDBMS's like Oracle or MS SQL Server. I guess we can always depend on clueless tech journos on a tight deadline to portay Open Source MySQL vs closed-source Oracle/MSSQL/etc as a cliched David and Goliath battle. yeesh
For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 5, Informative
I get so tired of reading all these "MySQL sucks" comments from the PostgreSQL crowd every time there is any mention of the two databases. Well, for whatever reason, this time I feel compelled to comment in return.
First of all, I remember back when I was trying to decide which of the two databases to use for my bicycle touring community website, crazyguyonabike.com, and I heard all the same arguments that MySQL is a "toy" that's simply an SQL interface to a flat file system, and how PostgreSQL was a "real" database with actual transactions, subqueries and so on... but then, digging further into PostgreSQL, I found out about the 8k row size limit, and the requirement to halt everything to do a VACUUM occasionally. That really set me back on my heels - 8k? That's really pathetic. Ok, so they've fixed that in the later versions, and the VACUUM also seems to be bit less blocking now, but still - it left me wondering just what else these zealots were conveniently choosing to forget about when recommending PostgreSQL. How about speed? How about all the anecdotal accounts of corrupted databases (again, probably improved somewhat more recently). What other major limitations are they conveniently neglecting to mention these days? I ask, because these people were making exactly the same noises back in the 8k rowsize limit, blocking VACUUM days as they are now.
Thing is, MySQL works really well right out of the gate for most things that people want to do in real life. Here are a few factoids for you:
MySQL *does* have real transactions. It has for quite some time now - just use the InnoDB table type. And for anyone who whines about this not being the default table - get a life! Choice is good, and I would say that for 99% of applications out there, you just don't need transactions. Go ahead and crucify me for saying this - I don't care. It works for a lot of people, many companies all over the world use it for heavy duty database work. I've used it for four years now, and it has *never* crashed on me, *never* lost any data. I use RAID and backup regularly too, but MySQL is ROCK SOLID.
MySQL is getting all these things like subselects and procedures, just with a different priority to PostgreSQL. So what? Again, I have never missed subqueries, and I have some pretty complex queries in my website. Again, go ahead and flame me, I don't care - it works for me, and it works for a LOT of other people too. Which brings me to another thing:
There is a definite sense of intellectual snobbery and elitism in many of the comments from PostgreSQL fans slamming MySQL. This reminds me of some of the people I used to know back at University - these are people who are so wrapped up in their own little cozy theoretical worlds that anything remotely practical or pragmatic in its approach seems to be extremely threatening. I think this is one of the big reasons for the bile - these people are simply threatened by the fact that MySQL is so popular and so much more used across the world. Could there also be a little tribalism creeping in here? You know, my team vs your team. They just can't seem to understand that BOTH databases work very well and BOTH databases have weaknesses, which BOTH development teams are working very hard to fix and make better. Getting religious about this sort of thing helps nobody. But, I guess, given the fact that Religion is in fact so widespread in the world, this would then also point to there being a somewhat large number of people who are so hung up on their own little certainties and fixed viewpoints that anything else just can't be left to stand. Like the Christian missionaries, they have to have everyone else adhering to THEIR point of view, regardless of the fact that there are, in fact, many "ways" to spiritual enlightenment (or data management). Again: Not everyone needs transactions. Many people just need simplicity and speed, and they get it with MySQL. And you know what, if they want transactions then they can have that too! Th
Re:For all the PostgreSQL zealots out there...
by
kpharmer
·
· Score: 1
> I get so tired of reading all these "MySQL sucks" comments from the PostgreSQL crowd every time there is any mention of the two databases. > Well, for whatever reason, this time I feel compelled to comment in return.
Point taken: postgresql used to have some performance and availability limitations, mysql still has functional and usability limitations.
> MySQL *does* have real transactions. which are implemented using a third-party product, are limited and aren't seamlessly integrated, and which can fail silently due to syntax violations!
> I have never missed subqueries yep, I've occasionally developed trivial databases without them. But I've seldom developed a serious database without them.
> There is a definite sense of intellectual snobbery and elitism in many of the comments from PostgreSQL fans slamming MySQL. Nah, more likely it's the disgust that the more experienced developers feel with an obvious charletan that claims that well-proven techniques aren't necessary. Kinda like if ten years ago Yuga had insisted that air-bags, seat belts, and bumpers weren't needed "by most people in most situations". Yeah, right.
Keep in mind that without referential integrity, transactions, and some other missing features - the product isn't a relational database. It's just an isam file with a non-standard sql interface.
And don't forget that each one of the basic core functional parts of a relational database (like referential integrity) are added gradually - with initial limitations that are incrementally removed.
That's a fine way to improve the product. But it was disingenuous and irresponsible of mysql ab to defend its weak functionality by claiming that transactions aren't necessary.
Re:For all the PostgreSQL zealots out there...
by
Anonymous Coward
·
· Score: 0
Agreed! I use mysql with a database that gets about 50 megabytes added to it (about 250,000 rows) a day and is currently about 10 gigs (I clean out the older stuff so it flucuates between 8-15 gigs). I read up on postgresql as a serious alternative and set up benchmarks for selects and inserts. I rewrote my application and tested it. It wasn't bad, but it wasn't as good as mysql. I have never had the data integrity problems mentioned (not saying others don't, but saying _I_ don't). Postgresql's documentation was definatly much less than mysql's docs. IIRC, PC Mag. did some benchmarking with a few databases (oddly enough postgresql wasn't in the crowd) and for speed and handling of large databases, the only database that kept up with Oracle was mysql. To each his own. Mysql isn't a cure all, but postgresql isn't the cure all people would like to believe it is either.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 2, Insightful
Thanks for nicely illustrating my point!
Nah, more likely it's the disgust that the more experienced developers feel with an obvious charletan that claims that well-proven techniques aren't necessary. Kinda like if ten years ago Yuga had insisted that air-bags, seat belts, and bumpers weren't needed "by most people in most situations". Yeah, right.
yep, I've occasionally developed trivial databases without [subqueries]. But I've seldom developed a serious database without them.
Wow, thanks! Another snide and elitist response! MySQL works very well for a very large number of people, thanks very much. Calling someone who challenges your viewpoint (that transactions MUST be used everywhere and if you don't do subqueries then you're somehow a charletan and not a "real" developer of "serious" databases) is just more of the same drivel I've been reading all this time...
You know, it's not the fact that either database has this or that feature that really grates on me here. It's the attitude of the people who make claims that you can only be developing "serious" databases if you require subqueries, or that "MySQL is a toy" and the classic "it's not a real database"... these are extreme and unnecessary statements that fly in the face of people's REAL WORLD experiences with this RELATIONAL DATABASE.
Sorry, but Yes, it IS a real database. And no, I truly don't appreciate the dismissive, elitist attitudes of people like you. You conveniently ignored the 8k row limits and the VACUUM blocking yet again, because it doesn't fit with your cozy world view. Oh well.
Nice try, but sorry, no dice. Don't you understand my main point, which is that by making your responses so repellent and insulting, you truly don't do yourself or anyone else in the PostgreSQL camp any favors. The zealots will just cheer (as usual) while the rest of us just sigh and discount any valid points you may have made because they are buried inside snide, intellectually elitist remarks.
Re:For all the PostgreSQL zealots out there...
by
kpharmer
·
· Score: 1
> Sorry, but Yes, it IS a real database. And no, I truly don't appreciate the dismissive, elitist attitudes of people like you.
Dude, don't take criticism of the mysql product so personally. Relational databases have been around a *long* time, and the basic functionality is *well* understood. If mysql ab hadn't taken the equivilent position to declaring OO unnecessary and delivering a new implementation of COBOL '68 - then they wouldn't be the recipient of so much *legitimate* criticism.
And don't act like we're calling your baby ugly. I viited your website - it looks fine, feels crisp, and appears to have reasonable functionality. Great. If you want to use mysql - and deal with silent errors, non-standard sql, sql limitations, etc - fine. Go for it. Whatever - you can still work around these problems and get a good product in the end. But please don't demonize everyone that levels a valid complaint about the mysql non-relational philosophy.
> You conveniently ignored the 8k row limits and the VACUUM blocking yet again, because it doesn't fit with your cozy world view. Oh well.
Yes - because these limitations are *gone*.
Re:For all the PostgreSQL zealots out there...
by
Anonymous Coward
·
· Score: 0
> the 8k row limits and the VACUUM blocking
Good point. The pain in the neck of dealing with inversion objects was why we abandoned PostreSQL. With MySQL, you just put your data in a standard INSERT statement. Having to put data into files then calling a proprietary PostgreSQL function was a pain. The other strange thing was that we found inserting the data was faster than reading it back, even for small tables. Since we read the data about 1M times more often than we changed it, PostgreSQL wasn't a good choice. Also, we had been banging our heads against the 8k row limit and having to divide data into different tables.
Having to lock-up PostgreSQL each night to vacuum wasn't a problem for us since we had a 30 minute maintance window each night, but I can easily see how that could be a problem for some people.
Re:For all the PostgreSQL zealots out there...
by
sillysurfer
·
· Score: 1
It sounds from the length of the brutal attack on Postgres that people in glass houses shouldn't throw stones. Pissing on your own doorstep eh? You complain about 'zealots' yet you yourself sound like you should join Ossama and his mates and go blow up the Postgres head developer!
As a professional consultant who has deploy lots and lots and lots of enterprise, small and medium stuff (think FT.com, O2, Vodafone, Schroders, etc etc) and having ran a consultancy the key factors in choosing a database are
1) Support - how many people know it and if it breaks can it be fixed in a cost effective and fast manner? 2) Reliability - does it go down and can we mitigate the risks with clustering? 3) DR - can a backup be easily restored? 4) Cost of both dev and licenses. 5) Does it meet our architectural needs? For example at one of my major clients we had a realtime billing system for SMS's. It had a high volume of data flowing from table to table. The original system had no stored procedures and took ages - like 35 hours for a days data. We re-wrote in stored procs and it flew - 600% speed increase. Could we do this with MySQL? NO!!!!!!
I don't choose db's for my customers just because I'm a zealot. Some implementations use Oracle, some Postgres, some MySQL, some Sybase ASE.
If the people on Slashdot who scream and shout utter rubbish actually thought of requirements I wouldn't keep turning up to customers who had inadequate, poorly maintained systems designed by schoolkids.
Get a grip. Think of the factors, risks and choose the implementation on that. Don't dive in thinking 'I only know mysql and everything else must suck' - do some research, draw up plans, ask friends and get in some consultants.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 2
I think you're the one who should "get a grip". If you actually read my post rather than instantly putting on your "flame anything that says anything negative at all with the word 'PostgreSQL' in the same sentence" hat then you would quickly realize that I am not making a "vicious attack on Postgres". I am making a vicious attack on the assholes out there who feel it is necessary to viciously attack MySQL for having the temerity to exist and actually be USED by, well, let me see, lots and lots of people. Very successfully, I might add, and for large installations, which I know must be a little galling for all you purists out there. Isn't it irritating how non-neat and tidy the real world is? Excrutiating that some people seem to be able to get by very well without subqueries or even (gasp) transactions and stored procedures? Wow, I sympathise. Life is hard.
If you read my post, you can see that nowhere do I slam PostgreSQL itself - just the stupid zealots who alienate real people (who might otherwise be interested in investigating the product) with their elitist and dismissive crap.
I don't need a treatise on how to select a database or consultants, thanks very much. Yet another smug post reeking of hubris and the usual blinkered thinking exhibited by zealots on a daily basis...
Comparing me to Osama (get the spelling right at least, don't you read?) and saying that I want to blow up anyone is in such poor taste that you pretty much invalidate anything else that comes after. Sorry, mate.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Yes - because these limitations [8k row limits and VACUUM blocking] are *gone*.
Again you missed the point - which was that the zealots were trumpeting PostgreSQL as the perfect solution for hair loss even back when these limitations were in place. Thus by extrapolation I am led to wonder exactly what else they must be conveniently papering over these days, given their credibility being shot by previous claims.
What we need is sensible, unbiased advice and opinions, not religious wars, which is pretty much the whole point of my posting today. I am most definitely NOT against PostgreSQL in any way, but I most definitely AM against people enaging in such witless, arrogant barbs that supposedly come from positions of experience and knowledge, but end up just putting down anyone with different outlooks about what's necessary for a "real database".
Re:For all the PostgreSQL zealots out there...
by
Anonymous Coward
·
· Score: 0
*never* lost any data.
how the fuck would you ever KNOW? MySQL eats all kinds of errors without a peep. You're a dork.
Re:For all the PostgreSQL zealots out there...
by
kpharmer
·
· Score: 1
> Again you missed the point - which was that the zealots were trumpeting PostgreSQL as the perfect solution > for hair loss even back when these limitations were in place.
Ah maybe so. Well, in the interest of helping to set the record straight, here's my take on that:
- 8k wasn't much of a limit until we started storing multi-media in databases. Prior to that it was rare to hit an 8k limit. Postgresql was a little late with their support here.
- mandatory maintenance downtime was common even in commercial databases until about a year ago I think, at least for reorgs. This wasn't too much of a problem really until the internet made it possible to do work around the work 7x24. Even today you're still looking at downtime - for backups with mysql and probably most configuration changes, upgrades, expansions, and tunings of either database.
So yeah - postgresql fell short of mysql in content management solutions two years ago, just as mysql fell short of postgresql in non-content management solutions. Today neither of the above are true. Postgresql has pushed back these limits and has improved performance. Mysql has made significant strides in improving its dbms functionality, but still has large gaps. It'll hopefully resolve these gap soon - but until then its primary value proposition is that it has better windows support, isp support, and documentation than postgresql. Over the long-term this strategy may pay off for mysql - build market share with a unique content management position, put out a lot of fud to deflect database criticisms, then bust its butt to get essential functionality in place before users begin to migrate other solutions.
But until this functionality in place mysql just isn't competitive in most database applications besides content management.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
But until this functionality in place mysql just isn't competitive in most database applications besides content management.
Oh come on, this is just more spin. You minimize PostgreSQL's weaknesses and pass them off as being "not very important until recently" - what utter rubbish. People have been storing data larger than 8K in databases for a heck of a long time without having to talk about "multi-media". Even a bulletin board application would need more than that... but, I don't want to labor the point too much, because the point (as I said previously) wasn't so much about bashing PostgreSQL, but rather pointing up the disingenuousness of certain people who have chosen in the past to gloss over these things in favor of "their team" while ranting on and on about how much of a toy MySQL is. PostgreSQL has fixed these problems - that wasn't the issue, but rather how the zealots lost credibility in my mind by papering over such issues back then. Now they are still saying it's the best thing since sliced bread, and I wonder, what are they glossing over now? That's the point. Credibility. If people only discussed the pros and cons in a more reasonable way, everything would be just fine. I can live with PostgreSQL being ahead of MySQL in some respects, if they can live with MySQL being ahead in others.
MySQL is perfectly feasible for a heck of a lot more than content management. It's a bit of a leap of logic to go from "A is good at X" to saying "A is only good at X". How does that go again? MySQL *has* transactions - if you want them. I've honestly never had a situation where I *had* to have subqueries (and, believe me, that doesn't mean that I've never developed a "serious" database). Similarly, triggers and stored procedures are a matter of taste - for every rabid proponent of these types of feature you can probably also dredge up someone else who has had to sort out the mess caused by putting too much application level logic into database procedures - it can be a real mess to manage and maintain.
So MySQL doesn't have all the features of PostgreSQL - of course not, but for some strange reason tons of people still like to use it and it works just fine day in and day out, quietly chugging away. I would posit that while the additional features of PostgreSQL are indeed very nice (I would like to work with it just as soon as I find the time and resources), there are probably few cases where you can't achieve the same functional results using MySQL. Anybody who slams MySQL based on transactions doesn't know what they're talking about - it has them. Has for a while now, but they are optional, which is no bad thing in my book, because they DO slow things down and in 99% of cases you just do not need them.
Anyway, good discussion - thanks for engaging.
Re:For all the PostgreSQL zealots out there...
by
Anonymous Coward
·
· Score: 0
Much of the time there's a non database copy of the data (paper copies, unformatted files, etc. etc.) and you can compare the data in the database to the raw data. On top of that, if there's something that one of your users swore they enetered that doesn't show up (i.e. case numbers, arrest warrents, booking info) you're going to hear about it.
Re:For all the PostgreSQL zealots out there...
by
imroy
·
· Score: 1
Anybody who slams MySQL based on transactions doesn't know what they're talking about - it has them. Has for a while now, but they are optional, which is no bad thing in my book, because they DO slow things down and in 99% of cases you just do not need them.
Hmmm, just thinking about these optional transaction-capable table types. As you say, they are slowler than the default table type. And I wonder how this "option" has affected the development and the pursuit of speed/efficiency. In PostgreSQL, there is only one table "type" and it supports transactions, as does all other aspects of the RDBMS. So any effort to speed up pgsql must work with transactions, no short-cuts there. But with MySQL, transactions are an option. I wonder if this has produced a kind of laziness with the developers, who can say "if you want speed, don't use transactions" instead of actually doing something about it. I wonder if anyone has done any benchmarks of MySQL+InnoDB vs PostgreSQL to see how the different transaction-capable DB's stack up speed-wise. Just a thought.
Re:For all the PostgreSQL zealots out there...
by
imroy
·
· Score: 1
8k wasn't much of a limit until we started storing multi-media in databases. Prior to that it was rare to hit an 8k limit. Postgresql was a little late with their support here.
Yes, multimedia and blogs seem to be the applications people are thinking of when they whinge about the 8K row limit. Hell, Slashdot was probably one of the early big users of MySQL. What these people never seem to think about is whether it's all that important, useful, or even clever to store large pieces of data (be it binary or text) in a RDBMS. Are you going to perform a query on the column storing a jpeg photo? For text (blogs, etc), I can maybe see the use of being able to simply search through the text. But IMNSHO, an RDBMS shouldn't need to also be a text search engine. Just put the damn data in a file, store the filename in the DB, and if it's text then you can use a purpose-built search engine like Glimpse or Namazu.
Re:For all the PostgreSQL zealots out there...
by
Sxooter
·
· Score: 4, Informative
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.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:For all the PostgreSQL zealots out there...
by
jadavis
·
· Score: 4, Insightful
I have been looking for a long time for a MySQL person to actually say something that bugged them about PostgreSQL, and why they couldn't use it.
When I started using postgresql, at 6.5.3, it was deficient in many ways. Advocates may have tried to hide these deficiencies at the expense of whoever they were advising. But, I never got any sense that the developers did.
I remember a post by someone on the mailing list that asked (and I'm paraphrasing here from memory, so I could be off): "Would you run your payroll system on PostgreSQL?" (implying that he bet his paycheck on postgresql) and a primary developer responded "not on 7.0, but on 7.1 [just released at the time], yes."
I really think that postgresql has moved a long way since that time. It's at 7.4.1 right now, and I I simply haven't heard reports for a long time about any sort of "weirdness". It's a 24/7 system now. Heck, I was running a 7.1.x system for a long time with no problems.
Now, I get the same feeling about hidden issues with MySQL from the advocates of that system. But I actually check up on my facts, and I've decided that I would prefer not to use a database that thinks Feb 31st is a date.
Granted, I understand that the features of PostgreSQL have to develop a track record of actually working. Well, all the things you mention were fixed at least a year ago, and yes, they do work.
I also understand that MySQL works for you. But what I don't understand is why PostgreSQL doesn't work for you. I'm not saying you should switch to postgresql, but I would like to hear of an actual problem someone had using it in the last 12 months (or heck, 24 months) that MySQL solved. What can PostgreSQL possibly do that would attract your attention again?
From my perspective, MySQL has nothing to attract me away from PostgreSQL. MySQL improvements have been suggested many times, and they're working on them. What improvements do you suggest for PostgreSQL?
-- Social scientists are inspired by theories; scientists are humbled by facts.
Re:For all the PostgreSQL zealots out there...
by
max
·
· Score: 1
MySQL works very well for a very large number of people, thanks very much.
This is because a very large number of people don't really need a database to store their data. They could just use a flat file, but MySQL is much more convenient to use, it allows for higher level programming. Good, use it. That alone does not make it more of a database system. Still, it is very useful and to the myriad of developers out there that don't really need a full fledged database system and knows MySQL like the back of their hand, this is a recommendation from me: use it! Keep an open mind though and try to learn other systems also.
Calling someone who challenges your viewpoint (that transactions MUST be used everywhere and if you don't do subqueries then you're somehow a charletan and not a "real" developer of "serious" databases) is just more of the same drivel I've been reading all this time...
Personally I don't run a critical system but I find it very comforting to know that transactions allow my tables to be updated without any raceconditions or unwanted side effects. Because I model my databases and normalizes them to 3NF or BCNF I always have several tables and thus transactions and subqueries are essential to me!
Many people out there don't know what normalization means and have one big table for everything, effectively duplicatind data, but for their use it works. I don't look down on them, but if they try convincing me that transactions and subqueries are bogus and can be solved within the application layer I know that they really have little clue of what they are speaking about.
You conveniently ignored the 8k row limits and the VACUUM blocking yet again, because it doesn't fit with your cozy world view.
Yes, 8k row limits might be a pain in the butt. But they are history now, and has been so for quite a while. Personally I have never had a problem with it for my projects, although I agree that that was the one of the big issues I had with PostgreSQL when I initially had to choose a system. But since MySQL lacked a few features i really needed, MySQL was never the choise for me.
Again, VACUUM blocking I have never had a problem with, but YMMV. Also, this is history, so why go on about it? Lets talk about todays limitations in the systems. If someone say something incorrect about todays MySQL, feel free to correct them.
What problems do you have with todays PostgreSQL? What could MySQL do for you that PostgreSQL couldn't?
If Oracle or MS SQL were free I would probably use them, but they aren't. Now i use PostgreSQL. I have yet to be shown where MySQL could be a better replacement for me, but if you can convice me, i'll switch!
Re:For all the PostgreSQL zealots out there...
by
Zontar+The+Mindless
·
· Score: 1
> I find it very comforting to know that transactions allow my tables to be updated without any raceconditions or unwanted side effects. Because I model my databases and normalizes them... Many people out there don't know what normalization means...
And you can't normalise MySQL tables? I've converted several "Hey, let's pretend it's just like Excel" horrors done in MS-SQL into *normalised* MySQL DBs, reduced their sizes on disk by anywhere from 50% to 80% and made them run 2-3 times as fast just by applying some basic normalisation techniques.
No RDBMS has a monopoly on bad design. None has a monopoly on good design, either.
MySQL has supported transactions and foreign key constraints for ages, using InnoDB tables. If I'm not mistaken, these will be added to MyISAM tables in MySQL 5.1.
-- Il n'y a pas de Planet B.
Re:For all the PostgreSQL zealots out there...
by
Anonymous Coward
·
· Score: 0
I don't need a grip, I am holding onto this keyboard quite tightly actually.:-)
No, my post was not a flame and it was not directed at you (I didn't trump up any one db, I said choose your db according to your needs).
I really hate people like yourself who are so blinking angry/vicious whatever. Why? Why? Why? There is no need to be so at odds with everyone in your postings. Step back and take a professional viewpoint - stay neutral and friendly and don't burn your bridges. Your CV is fantastic. But sadly more often than not, the quiet, Indian fellows who listen and answer with respect and decency will be taking the jobs. We are all on the same team. If you actually look at our industry the long-term view is bleak.
I never suggested you needed a systematic, usually extensive written discourse on database technologies. Any no my posting was not arrogant at all. Blinkered thinking?
Lets get this straight - my post was AGAINST BLINKERED THINKING. I nearly pissed myself with laughter when I read your posting... hilarious!!!
Its actually Usama Bin Laden - so we were both wrong. You should do some research before steaming in (http://www.fbi.gov/mostwant/topten/fugitives/lade n.htm)
Ok- and to set the record straight - here are my prime reasons for choosing:
Postgres:
1) Syntactically almost identical to Oracle 9i - including the Pl/SQL language. Means upgrades are fairly seamless 2) The DDL's are fairly standard 3) Has proper core functionality I know how to use and is supported by Redhat.
MySQL:
1) Fast (but doesn't do stored procs - so actually its bloody slow for some things because of the appserver/network overhead) 2) Good with PHP and has good drivers. 3) Runs on win/32 well
Oracle:
1) Fully featured 2) Industry recognised 3) You can get more jobs knowing Oracle. Exactly how many jobs on Jobserve ask for Mysql experts and pay well???? NONE! 4) Supported 5) Enterprise ready 6) Portable data engine - multi platform.
The biggest killers against MySQL are not features - they are corporate recognition and portability. Ernst+Young won't touch it, Accenture keep well away, IBM won't go near it. The list is endless. Until such times as these things change, you can happily sit on a low hourly rate writing MySQL. At least with Postgres you can easily port forward to Oracle. With MySQL you effectively will have to port a lot of stuff - and believe me I have tried!
Thats why Object-relational products are going to break the market up quite well. With FastObjects/JDO and CMP you can effectively choose any DB.
Basically anyone with any cash and serious about business uses Oracle or DB2. Maybe thats why I'm swinging away from Open Source DB's and getting Oracle certified.
I'm off snowboarding to Meribel... enjoy writing postings on slashdot - what an excellent way to live!
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
I am not "remembering" past statements from PostgreSQL fanatics - they occur on a daily basis in the here-and-now.
I am against unfair statements from any direction, including MySQL. I wasn't aware of the "lies" that you attribute to MySQL AB... well, if they said things that were wrong then they are wrong, and that's clear, no quibbles. But does that excuse the behavior of people from the PostgreSQL side? Do two wrongs make a right? I don't think so. If you want to be mature about it then by all means discuss the shortcomings of both products. Have opinions about MySQL AB, I have no problem with people bringing up mistakes or outright lies. But the posts I have read so often never mentioned that - they never came from an position of "well, MySQL AB said such-and-such, which is clearly untrue". They just said "MySQL is a toy, and clearly unusable for any serious database application". This is just wrong, and really no better than any of the slander that you allege coming from MySQL AB.
As I think I've made clear, I don't think MySQL is the God of database, and I don't think that PostgreSQL is either. They both excel in some areas and are wanting in others. I have used MySQL for a long time and it is indeed rock solid and extremely fast. If people want to criticize it, please let's do it from a position of enlightenment and reason, not senseless elitism and arrogant stone throwing.
Making claims about MySQL AB (the company) as a result of them making assertions that are clearly wrong is fine in my book - but that's not what I read on a daily basis on Slashdot, whenever MySQL is mentioned.
As for the 8k row limits, so, in this regard, MySQL was in fact *better* than the big databases such as MSSQL and Oracle? So why, instead of complementing MySQL for this accomplishment do we slam it as a toy database? It seems that rather than accept that MySQL has (or had) an edge in one particular area, instead you seem content to use the Oracles and MSSQL's of the world as excuses for limitations in PostgreSQL. Listen, this is all in the past anyway, because these limits are gone now, but the point I am making is that everybody seems to want to spin reality to suit their own bias. I freely admit that there are areas of MySQL that need improving - all products do. But it's all this "MySQL is a heap of steaming crap" that is just WRONG and needs to be countered. Saying nothing about "lies" put out by MySQL AB, simply that I want to see reasoned discussion.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
I too would love to see the things you are talking about. As I said in my original post, I'd love to see impartial benchmarks, for one thing - benchmarks with both products done with default "out of the box" configurations and then with both fully tuned by respective experts. This would help clear up a lot of the FUD that flies around. Then, people could make a real decision based on facts, not on silly anecdotal opinions. For example, how about the "MySQL crumples under load"? I'd love for someone to do tests that can be confirmed by anyone (including MySQL AB) and give a clear indication of what happens. I mean, it might just be a stupid semaphore bug or something. It would help everyone to just get it out in the open and fix it!
I think people tend to assume partisan motives whenever someone supports one side or the other - I am not partisan toward MySQL or PostgreSQL. In fact, I would move over to PostgreSQL very quickly if I could be confident that I would not be losing out in the reliability, features or speed of MySQL. I am simply frustrated that everything I read seems to be either parroted mythology or else outright lies and mud slinging. There are still people out there who declare with perfect certainty that MySQL does not support transactions! Well, it does. And then these people complain that InnoDB tables (which support transactions) are not default. Oh well.
Listen, if I could get a real list of pros and cons done in a truly fair way (not by someone who has a secret like for one or the other) then I think this would be extremely valuable. Plus, it would spur the losing database developers on to make their product better. However, I know database benchmarks are not a simple thing... if anyone has any ideas on how to do this, then I'd love to know.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
You're the one who first characterized my post as a "brutal attack on PostgreSQL", mate. Do you really expect me not to respond to such things? Once again: If you read my post carefully then you'd realize that I was not attacking PostgreSQL, but the religious fanatics that seem to follow it.
I hate to say this, but I will anyway: You come across as something of a smarmy arsehole, to be honest - not someone I would like to know in personal life. You are one of these people who is quite happy to make all the inflammatory remarks you like, and then accuse other people of "needing to get a grip". Tell me, what's it like being at the center of your own little universe?
I speak my mind. The constant flaming of MySQL made me want to counter the FUD - which I did. I wasn't attacking PostgreSQL. Clear enough for ya?
Thanks for the comparison of features - this is the kind of thing that should be thrown around, not the "MySQL is a toy" remarks that are so common hereabouts. You certainly seem to have technical expertise, I only wish you had more ability to parse English and grok what effect such inflammatory remarks will have on other people. Or, perhaps you really do realize this already, and this is just your way of debating - make remarks and then berate the other person for taking you to task on them. Oh well. Sad either way.
Incidentally, "Osama" is a common spelling used by all the major news networks. I'm somewhat more inclined to take the BBC's word in these matters than yours.
At least I have the guts to be open about who I am, anonymous coward... enjoy your snowboarding.
Re:For all the PostgreSQL zealots out there...
by
max
·
· Score: 1
And you can't normalise MySQL tables?
I am sorry if I wasn't clear in my previous post. Of course you can, but most people don't normalize their tables. In fact many use one, the table, to store everything. Then they have little if any use for more "advanced" features. Most people don't need referential integrity simply because everything is stored in a huge table without references. Then they never have to use subqueries to find the complex key from other tables when inserting new data. They do not worry with handling several tables, so often no transaction need. For them MySQL works fine and probably faster than any other database since they don't bother with transactions. In fact, they use MySQL more as a data storage not a relational database. It's ok, it works for their application. My objection was when people say "most people don't need..." without looking at their application. "Most people" don't need a RDBMS. This doesn't somehow make MySQL automatically and univerally superior. In some applications, yes. As a full fledged RDBMS many seem to object, I am inclined to agree with them. Misunderstand me right; it is even better to use MySQL even if in a bad way than for every programmer to implement his own datastorage from scratch. The development cycle becomes much more rapid when you just have to open a database connection, throw in a few INSERTs and SELECTs and have abstracted your project to a higher level than to dig around in your filesystem and parse homebrewed fileformats.
No RDBMS has a monopoly on bad design. None has a monopoly on good design, either.
Of course not. I have seen one of the ugliest database designs ever done on an Oracle 8i-server, then to be ported over to tha PostgreSQL-server I once set up at my old work. I almost wept. But IMHO a system can "encourage" or "discourage" bad design. I think that allowing users to choose away transactions is bad, perhaps you are of a different opinion, ok.
MySQL has supported transactions and foreign key constraints for ages, using InnoDB tables.
Yes, but it is not used for every table, only where the designer has agreed to use InnoDB-tables. This is not something I really like with a system that is to be a RDBMS. Today you can claim that this is good because it allows users to choose between raw speed and data integrity. But this hasn't always been like this and to me it seems like the lack of transactions in orignal MySQL was a poor design decision that has been "fixed" through the design decision to allow multiple types of tables and the later InnoDB. Two ways of looking at the same issue.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
If you re-read my post, you'll realize that my point was not to target specific features of PostgreSQL, but rather to bring attention to some examples that were glossed over by the PostgreSQL zealots a couple of years ago. These people lost all credibility with me because if they trumpeted PostgreSQL as the best thing since sliced bread back when it had these limitations, then I just have to wonder what other bugs or limitations might we not be hearing about these days? Again, not to "attack" PostgreSQL - all bugs get fixed, and features get added. I am objecting to an epidemic of intellectual snobbery that I find extremely objectionable. Hence my posts.
I am targeting the people who slam MySQL as being a "toy database". Your attitude pretty much falls into this category in that you seem to be saying that it's not even a real database! Different words, same obnoxious attitude. You seem to be under the impression that all databases have to use transactions all the time. Nothing of the sort - if you want transactions then use them, but you don't have to. Some applications value speed (and a reasonable level of security & backup strategy appropriate for the application). This doesn't mean it's not a database.
See, more elitism and arrogance. This is exactly the attitude that got me going in the first place.
Sorry, but your post just doesn't convince me at all, and in fact just confirms you as just another arrogant elitist. I know what a "database" does, believe me, and MySQL does that job admirably.
Re:For all the PostgreSQL zealots out there...
by
max
·
· Score: 1
I have re-read your post and I find it very disturbing that you run around calling other people, including me, arrogand and elitist, just because our definition of a RDBMS does not happen match your. I am inclined to agree with those you call arrogant elitists that a database should always use transactions to protect your data. After all, transactions are there to protect your data, hence database. Note that transactions alone don't do magic, other features as triggers and foreign keys are needed too.
So sorry, your post don't convice me at all either, just confirms that our standpoint are completely different. What disturbs me is that you have to resort to labeling people as "arrogant" and "elitists" just because their viewpoint differ from yours. That kind of behaviour makes me sick. I feel sorry for you.
And to all other out there, check what your application need. If it is raw speed and no data safety, MySQL/MyISAM is great. If you have to have transactions MySQL/InnoDB might work, especially if you want to combine both transactions and non-transaction tables. Otherwise, check out PostgreSQL for example (there are a few others like Firebird but that I have no personal experience with so get recommendations from someone else). It is not as bad as people said. Easy to set up, get running and the docs aren't bad. I have learned from them, I think you can too.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Well, you're free to disagree of course. I have no problem with people saying "I think this database is better because it has xxx and yyy, which I personally think are important to have". However this is very different from saying that a tool is "not a database" or "a toy" (a frequent term used to describe MySQL by some PostgreSQL fanatics). Whatever you say to the contrary, this sort of thing is clearly done in a spirit of insult and disparagement, not to say condescending in the extreme. If you want to pretend that you're being all even-handed and logical about this then you can go ahead and delude yourself, but I just can't agree that this is where you're coming from. In a nutshell, many of the people who slam MySQL so aggressively do it in an extremely offensive way - not in terms of comparing features, but rather in terms of saying that "MySQL is not a real database" or some such nonsense. This was the original purpose of my post, and I stand by it - you clearly can't deal with other people disagreeing with your opinion, otherwise you wouldn't be replying. So it's a little disingenuous to accuse me of intolerance toward other people's disagreement with my position!
Listen, once again: I have absolutely no problem with PostgreSQL. I'll probably try it out properly at some point, when I have the time and resources. In the meantime, I am using MySQL quite successfully, as are many, many other people. You can use MySQL to manage real data, in a real database. You have the option to utilize transactions using InnoDB, or fast retrieval tables using MyISAM. You have, in a nutshell, a powerful tool for doing real work and managing real data. Don't try to characterize this as a "toy", because it simply is not true. Sorry if this grates on you, but it's a fact. Live with it.
Re:For all the PostgreSQL zealots out there...
by
babbage
·
· Score: 1
MySQL, on the other hand, was designed from the start to be fast as hell and reliable, at the expense of things like, uh, transactions and subqueries and foreign keys and procedures and... yes, and a WHOLE BUNCH OF OTHER STUFF WHICH A LOT OF PEOPLE DON'T NEED AND NEVER, NEVER MISS.
Their loss. If you can do without transaction control & subqueries, good for you. Foreign keys, on the other hand, are really useful: they're basically an effiencent way of ensuring that all the info in your database actually interrelates properly. Trying to do a cascading delete without them -- where you want to get rid of a row from one table, but one or more rows from other tables point to it, and others may in turn point to those rows, etc -- is a royal pain in the ass without some kind of referential integrity mechanism like foreign keys. You basically end up having to code by hand the deletion where a database engine with foreign key support could have done all the work for you, and in a consistent, reliable, and even reversible way.
I'm not saying MySQL doesn't have a place. I myself use it all the time, and for my needs it's simple & easy. For web sites, its deficiencies are probably immaterial for the most part, and in other contexts, you can either ignore the problems or write database interface code to manage the shortcomings. But the shortcomings are real, and they do keep MySQL from being a serious candidate in certain contexts.
A good analogy might be web servers. Apache, from the start, has emphasized correctness over speed: it has never promised high throughput, but it guarantees correct, HTTP-spec compliant behavior in all situations. That's the PostgreSQL design philosophy. MySQL is more like Tux or something: small, fast, handles the common case well, but degrades badly and isn't as flexible as the more compliant server.
Another analogy might be to programming languages: maybe MySQL is the Perl of database servers. It's sloppy and ignores some of the rules, but it's easy to learn & use, and it mostly lets you do what you want to do without getting in the way. On the other hand, if you want to do more "serious" things with it, you need to have some self discipline & rigor -- the tool isn't going to do these things for you. So in Perl you have to consciously use strict;, you have to plan for good OO coding & abstraction of functionality into modules, and you have to resist the urge to let your code degenerate into over-clever line noise. In MySQL you have to choose table types that provide the "standard" database functionality, and/or you have to hand-roll this stuff with support code. This kind of thing is perfectly defensible, but you have to expect funny looks from the people that prefer to work with tools that are more rigorous and less forgiving.
In any case, the point is to be aware that the shortcomings of MySQL are real, and really shouldn't be swept under the rug. You can ignore them, but in the long run, it's better to be aware of them so that, when the time inevitably comes that you have to deal with them, you know what's going on...
Re:For all the PostgreSQL zealots out there...
by
Cajal
·
· Score: 1
"If you re-read my post, you'll realize that my point was not to target specific features of PostgreSQL, but rather to bring attention to some examples that were glossed over by the PostgreSQL zealots a couple of years ago"
Actually, the 8K row limit was well-documented. Checking archives of the PostgreSQL mailing list confirms that there were many posts about it, prior to PostgreSQL 7.1 (released in early 2001) which removed the limit. In fact, there is a web page, PostgreSQL Limits, located just 2 clicks off the main PostgreSQL site, which spelled out these limits. This page has been there for years, as verified by the Wayback Machine.
Further, the need to reguarly vacuum databases hasn't (and isn't not) glossed over. It's well-documented, listed in numerous FAQs and tuning guides, and comes up all the time in #postgresql on openproject.net.
I'm really not sure where you got the idea that these aspect of PG (one of which was removed over 2 years ago) were "glossed over." Nor do I see what relevance they have today.
Re:For all the PostgreSQL zealots out there...
by
max
·
· Score: 1
I can agree with you that many XXX fanatics slams YYY fanatics (in this case XXX=PostgreSQL and YYY=MySQL). The opposite is very much true also. I mean, you brought up how other people in this thread avoided the "8k row limit" and "vacuum locking", two historical issues you just brought up to illustrate how badly people behaved in the past! That would be as if I tried to talk about pre-InnoDB/Berkley DB MySQL. Hardly a constructive discussion?
Many people could really do with transactions (and triggers and foreign keys), just to make sure that their data is intact, especially since they don't need that extra speed non-transactional tables buys them. But my standpoint is clear in this case, if you choose away transactions you should know what you are doing, many people do but even more don't. There are many different kinds of solutions to storing data, but when it comes to databases my first priority is data integrity. Obviously others have other priorities. Consider that there are many ways of storing data, filesystems, LDAP, RDBMS, in-memory, etc. Use the solution that suits you.
And come on. You too would reply if you were being called things.
A last thing: do try PostgreSQL out, it doesn't take much time or effort. A friend of mine with only very limited MySQL experience got started with PostgreSQL in less than an hour, someone with your experience should be able to do it in notime. And it is able to run on very crappy hardware, I don't think it requires much more than MySQL.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
I was referring to certain of the zealous advocates of PostgreSQL, not the developers. Of course this sort of thing would have been visible if you wanted to do the digging - I never implied anything else. What I objected to was the fact that these advocates were trumpeting PostgreSQL as being clearly better than MySQL at a time when it had these glaring deficiencies - so, by extrapolation, I have to wonder what else is being glossed over these days when these same zealots are saying exactly the same thing? It's a question of credibility. Not to slam PostgreSQL itself - I'm perfectly aware that all tools have their limitations and both MySQL and PostgreSQL are making fantastic progress. What truly irritates me is that some people insist on disparaging MySQL as a "toy", "SQL interface to flat file system", "not a real database" etc. These are clearly untrue, hence my little posting frenzy of the last couple of days. I am trying to set the record straight, not in an effort to discredit PostgreSQL (it's a fine package, no doubt), but rather to redress the balance. There seems to be a very vocal group of people who insist on slamming MySQL at every opportunity, and my experience with using MySQL over the last few years has left me very impressed with it. MySQL is a real database - sure, it lacks some of the features of PostgreSQL, but that doesn't mean it's not a "real database". Many of the more advanced features are simply not needed by most people 99% of the time, for real-world projects. To imply that there is some kind of absolute standard for all data access which means that MySQL has to be discounted out of hand is really just beyond the pale.
Re:For all the PostgreSQL zealots out there...
by
Cajal
·
· Score: 1
Funny that you seem so intent on bashing these mythical PostgreSQL advocates, yet you ignore all of the pure BS that's been spewn from MySQL advocates and from MySQL.com itself. They have posted clearly skewed benchmarks between their product and PG and have outright lied in claiming that their database doesn't need "high-end" features like transactions, referential integrity, validity checking on inputs, etc.
Secondly, I wouldn't say that MySQL is making "fantastic progress." Yes, v4 is better that 3.23, but a lot of the new features (transaction, foreign keys, etc) are half-assed implementations and are trivially easy to disable or bypass. This is in addition to its numerous design flaws, which are well documented on the MySQL Gotchas page. Yes, every program has bugs, but the items listed on MySQL Gotchas go beyond mere bugs - they are fundamental design flaws. It is exactly these flaws which show no sign of being fixed.
Finally, I have to say that perhaps the biggest disservice that MySQL AB (the company) has done to the database commuity as a whole is to dumb it down. They have created a mindset where raw speed is seen as the most important factor in choosing a DBMS, and further, that the DBMS should be a dumb, raw datastore, with any data processing (no matter how basic) done in the application. They have eschewed compliance with the SQL standards. They have managed to convince a large number of developers that anything beyond SELECT, INSERT, DELETE and UPDATE are "high-end" features. This is simply not true. Foreign keys, referential integrity constraints, CHECK constraints, datatypes that work (like a good DATE datatype) matter.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
MySQL AB have not eschewed compliance with the SQL standards, as you can see for yourself from their documentation. To quote: "We aim toward full compliance with SQL-92/SQL-99; there are no features we plan not to implement."
Your first line, regarding "mythical" PostgreSQL advocates, is really laughable. You must be blind not to see them every time MySQL gets mentioned (even when the subject has nothing whatsoever to do with PostgreSQL)... now, I don't mind people comparing features and saying that they prefer PostgreSQL because it has x and y and z and MySQL doesn't. However, there is a line here in terms of being obnoxious and insulting, and this is what I object to. People who say that MySQL is not a real database, or that it's just a toy, or that it can't be trusted with anything - this is just wrong. Sorry. Wrong wrong wrong. MySQL may not have all the advanced features of PostgreSQL, but that doesn't mean it's a heap of steaming feces! That's just too extreme.
I know that a lot of the stuff that has been said on *both* sides of the debate has been controversial, and honestly I don't know enough about the details to know who started it or even who's right or wrong about the details. All I know is that we have two Open Source databases, and I've been using one of them for a number of years now, without any problems, to take care of reasonably complex databases - and so I *do* have direct experience of MySQL. It works very well. If you don't like it because of certain features lacking, that's fine - you're perfectly free to dislike it. But I wanted to counter the people who put it down in a way that I simply find objectionable. It doesn't mean that I buy into any of the previous baggage floating around regarding what's been said in the past, but if the only reason people are saying such things is because of perceived injustices of the past, then they should be open about it - otherwise they are being disingenuous, dishonest and falling victim to the same unjust behaviour that they are claiming to be so sore about themselves. Saying "MySQL is a toy" or "MySQL is just an SQL interface to a flat file system" is a different kind of criticism to "MySQL AB has spread untruths about PostgreSQL in the past".
Incidentally, why should it be a "disservice" to the database community to "dumb down" a database? Should databases remain the pure hallowed domain of database wizards who understand normalization and relational theory? Why shouldn't developers have access to a tool which performs well and does the job that is required for many, many cases? MySQL AB haven't "created a mindset" based purely on speed, they just made a product that was extremely easy to use (for developers, not end users) and it "just works". So then they realized that people wanted more stuff like transactions and subqueries *sometimes*, so they put that in... I don't see anything wrong with this incremental approach. MySQL 4 involved substantial code changes, I think, so they are obviously not afraid of redeveloping when it makes sense for new features. This is true for any project.
You may find the features you list essential, but realize that other people do not. Doesn't mean they are uneducated yokels, just that they don't need it. They can learn about this stuff and get into using databases without immediately running into all the complexity that is included with the more advanced packages. Later, if they find they need something that is not included, then they can move over to use something else like PostgreSQL - but people aren't really doing this in reality, because MySQL is "good enough" for most things. It's not perfect, but it certainly does the job and is being used by lots of people around the world. This may grate, but it's important to realize that this popularity is not due to people being led like sheep - it's because MySQL *works* and it works rather well.
Re:For all the PostgreSQL zealots out there...
by
Cajal
·
· Score: 1
MySQL AB have not eschewed compliance with the SQL standards, as you can see for yourself from their documentation. To quote: "We aim toward full compliance with SQL-92/SQL-99; there are no features we plan not to implement."
Oh, I'm sorry. I thought standards-compliance meant actually implementing code that conforms to the published SQL standards, not just saying that you will do so in some mytical, unreleased future version. My mistake.
. People who say that MySQL is not a real database, or that it's just a toy, or that it can't be trusted with anything - this is just wrong.
No, it's the truth. MySQL lacks any data integrity features. It silently alters table definitions, silently truncates input, performs no range checking on inputs, etc. Just because MySQL doesn't give you an error when you INSERT new data doesn't mean that that data was stored correctly.
It works very well. If you don't like it because of certain features lacking, that's fine - you're perfectly free to dislike it.
My dislike of MySQL has nothing to do with it not implementing certain features. It has to do with it implementing things incorrectly. MySQL doesn't do transactions correctly, it botches up foreign keys, its NULL handling is horrible, etc.
Incidentally, why should it be a "disservice" to the database community to "dumb down" a database? Should databases remain the pure hallowed domain of database wizards who understand normalization and relational theory?
Um, becuaase you can't dumb down everything. I think it's great the MySQL is easy to use. But the problem is that you do need to understand a few basic concepts before you starting writing SQL. You need to understand normalization. You should understand what a foreign key is. You should have a basic idea of how transactions work. None of these concepts are terribly difficult to grasp. Hell, SQL for Dummies covers them all!
MySQL AB haven't "created a mindset" based purely on speed
Oh they absolutely have! Monty has said numerous times that he values speed above all else, since that seems to be MySQL's major selling point. He's said that he'll try and implement standards-compliant features, but if they interfere with the speed of the DBMS, then he won't. And there are droves of brain-washed MySQL "DBAs" who don't want foreign keys, stored procedures, etc to be added to MySQL because they fear the DBMS will slow down.
You may find the features you list essential, but realize that other people do not. Doesn't mean they are uneducated yokels, just that they don't need it.
No, that's exactly what it means. If developers would take the time to become familiar with the basics of database admnistration, then they would realize that referential integrity and transactions are essential to a relational database. The problem with these fly-by-night "DBAs" (whose only exposure to databases is reaading the MySQL section of the PHP manual) is that they think learning a few SQL commands makes them database experts. It doesn't. This isn't elitism. This isn't snobbery. It's the truth.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Oh, I'm sorry. I thought standards-compliance meant actually implementing code that conforms to the published SQL standards, not just saying that you will do so in some mytical, unreleased future version. My mistake.
So now you're just being childish. Before you said that MySQL were abandoning the SQL standards, I corrected you, and now you sniff that well, it's not all done yet. Pathetic, really. You are descending into the realms of shrill "everything and anything the other guy says must be wrong, no matter if he has any actual points"!
Listen, you're very welcome to dislike MySQL. The way in which you seem intent on breaking down my post bit by bit and trying to make out that I am totally, completely, 100% wrong about everything under the sun really just says more about you and your religious hatred of MySQL than anything else.
Tell me, if MySQL is not a real database, then how and why are so many people using it on a daily basis to, well, manage their data? Whatever your views on data integrity, transactions, truncations etc, this glaring fact must be more than a little inconvenient. If the thing didn't work (and work rather well) then people simply wouldn't use it. I understand totally how infuriating this must be to purists who think that everything must be totally theoretically correct and complete and neatly tied up before it can be even considered... but, sorry, this just isn't the way the real world works. Truth is, MySQL is very much good enough for many, many applications.
I will grant you that Monty has perhaps emphasized speed as a priority over completeness. However, I still don't think that he "created a mindset based purely on speed". People who are creating applications simply want the fastest, simplest solution that will do the job - and MySQL fills that niche admirably for a huge number of people. Why go for something which is much more complicated and slower if there's just no need for it? Sure, you can make all the arguments about the quirks of MySQL and the lack of this or that standard feature, but it all comes down to this: MySQL does the job, very well, sufficiently, for a large number of people.
I suppose you can look at it a bit like Perl: Many people dislike it for being "messy" and inconsistent, and lacking in many of the belts and braces that enforce good practices in other languages (e.g. strong typing). However, Perl is enormously useful for all sorts of applications, because it is fast (to program, if not the fastest running) and simple to use. You can write a one line "Hello world" program in Perl, as opposed to the equivalent monstrosity in, say, Java. Yes, many people dislike Perl intensely, but it does the job, and does it well. There's even an acronym - LAMP - Linux, Apache, MySQL, Perl (or PHP). People use these tools to do great things. To try and imply that MySQL is "not a real database" is just ignoring the realities. And to pretend that all these people are not managing real data is also being more than a little blinkered!
Listen, I'll readily grant that PostgreSQL has many features that MySQL does not. It (and other databases) will probably catch up to MySQL in speed terms (if it hasn't already). MySQL, meanwhile, will add features and try to fix all the bugs that seem to be quoted regularly here on slashdot (not that I actually notice or am affected by any of these special cases on an everyday basis)... all this does not in any way mean that MySQL is a "toy". There will always be areas in which one is better than the other, but MySQL is now, and always will be, a real database, used by real people, for real work. Sorry! Just a fact.
Have a nice day!
Re:For all the PostgreSQL zealots out there...
by
Cajal
·
· Score: 1
This isn't being childish at all. MySQL isn't standards-compliant. They've put out a web page saying that at some point in the future, they *might* be standards-compliant if it doesn't slow down the DBMS too much. That's not a committment to standardization. The RDBMS market is already fragmented enough with proprietary SQL syntax - MySQL doesn't need to contibute to that mess.
As for the rest of your post, I have to disagree. Yes, a lot of people use MySQL. So? You can make MySQL sort-of work, but you have to write a lot of extra application code to do it, and you still lose a lot of capabilities as well as safety. If you're going to the trouble to install and configure MySQL and design a database, clearly you care about your data. Why use a DBMS that has extremely limited data integerity abilties? This isn't some pie-in-the-sky academic argument; it's very much "real-world".
Unfortunately, most databases today are installed and run by people who aren't familiar with database management. Often, they're setup by programmers or sysadmins who have only read a HOWTO on setting up a DBMS. This is unfortunate, since it often means that they miss out on more advanced features which make their lives easier. Yes, I said it. Advanced features (can) make life easier. They aren't just there to satisify elitest database snobs sitting in their university offices. Doing referential integrity checking in the database itself is much, much easier than doing it in your application code. Doing input validation in your database can save you from corrupted data, which can save you a lot of time in the future. It's better to do just a little more work upfront and not have to worry about a whole range of problems later.
They don't realize that they are putting their data at risk by not using foreign keys and transactions. Add to this the fact that MySQL silenty alters data and table definitions, and silently passes errors, and you have a disaster waiting to happen. I've seen MySQL databases which contain corrupted data, but the DBA adamantly claims that the database is fine because "MySQL has never printed an error." Of course it hasn't - it never does!
Your argument that MySQL is OK because it's popular just doesn't hold up. As an analogy, consider filesystems. The FAT filesystem is probably the most popular fs in use, but I'd argue that it's a toy FS compared to any Unix FS, and that it certainly shouldn't be used in nearly ever case where it is.
What's sad is that database design isn't some black art. Relational databases were designed for use in the real world. In the late '70s, researchers at IBM were unsatisified with the crappy database products on the market then and invented relational technology to address those problems. It has never been some ivory tower, academic technology. Further, the basics of sound database design aren't difficult to learn. Like I said in a previous post, SQL for Dummies covers everything you need to know for designing and running a basic database.
My gripe with MySQL is that it doesn't implement these things properly. Foreign keys and transactions just don't work right in MySQL. For years, MySQL AB claimed that it didn't need "advanced" features like transactions and referential integrity, and they hyped up ease of installation and speed. Now that they have finally realized that they do need these capabilites, they're not implemented correctly. I fail to see why so many people defend this software, especially when there are other open source databases (PostgreSQL and Firebird come to mind) that have had mature, working "advanced" features for years! Why wait for MySQL 4.1 or 5.0 to stabilize (which could take years), when you can have these capabilities today with other free software?!
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Sorry, but you keep on stating your opinions as if they are fact. MySQL does not "sort of" work, it *does* work, no question about it. You don't like it, and you've stated your reasons why for posterity, and I have the feeling that I could state my feelings on the subject until I'm blue in the face and still neither of us would budge one inch.
Fact is, I don't just say MySQL works because it's popular (though the fact that it *is* the most popular open source database in the world should give you some pause) - I say it works because I know this from personal experience. I have been using it every day, for the last four years. It has *never* failed on me. Sure, it has some features missing that other databases have, and it may not have all the belts and braces of other tools, but it really does work very well, believe me. PostgreSQL had problems with stability until recently, all tools do, but I wouldn't say it was a heap of shit just because of that. PostgreSQL has its uses, and so does MySQL.
Listen, you don't like it - I get it. We don't need to go around in circles. But what I don't understand is your obvious hatred of MySQL... it's just a tool, and I am telling you that it does work, for me and for a lot of other people too. Why get so religious about it? This is like Christians who insist that theirs is the One True Religion and everybody else's religion is just plain wrong. Ok, so here we're talking about specific features rather than relative merits of my heaven vs your heaven, but the point is that a database is for storing and accessing data. MySQL allows you to do that. Does it have all the features of other databases? No. Does it work very well for many, many real world applications out there? Definitely.
By the way, it's incorrect to say that MySQL "never" passes an error. It does. I think what you're referring to is cases where MySQL attempts to make reasonable assumptions in situations where different clients may have varying ways of making a query, and "default" behavior can reasonably be triggered in case of ambiguity. This has honestly never caused me a problem - in fact, you could even make a case for this being more "fault tolerant". MySQL does issue errors for real problems.
If you don't like something because it lacks some features, then fine. But please, learn to deal with the fact that not everybody shares your purist view of the world, and moreover it grates to hear that the tool I use every day is "a toy" or "not a real database" just because it doesn't come up to your own arbitrary standards. I've no doubt that we could argue until the next year, but I hope we can put this thread to sleep now and just accept that we disagree. Anyone following this should have been able to get the gist of the arguments by now, so any more would just be repetitive (too late!)...
Have a happy new year, best wishes for your data integrity, may none of your transactions need to be rolled back, and may all your foreign key constraints be satisfied...;-)
Re:For all the PostgreSQL zealots out there...
by
Cajal
·
· Score: 1
I'm going to respond one final time and then I give up.
This is not a religious argument, and I am sick to death of people trying to portray it as such.
Just because the MySQL daemon process does not crash does not mean that MySQL is a reliable datastore. I simply do not trust MySQL to reliably store data, since it performs so many silent modifications to both the table schema and to input data itself. These design flaws are well documented in the MySQL Gotchas page. You claim that you've used MySQL for several years without incident. I've also used it, both 3.23 and 4.0.1x, for over a year and have had nothing but problems with it. (As an aside, I don't know how you're claiming that PostgreSQL has had stability problems "until recently" -- I've run several 7.1, 7.2, 7.3 and 7.4 databases for about 4 years with no stability or performnce problems at all.)
If a DBMS can't do exactly what I instructed it to do, it should raise an error and abort. It should not silently modify data or make a random guess about what to do. This is not desirable behavior. Frankly, this is a lesson that every programmer is taught in their first compsci class. The problem is that MySQL wants to be newbie-friendly, so it silently passes errors. This statement does not make me some "purist" who's out of touch with the real world, it's just how SQL is designed.
SQL is not HTML and it should not be parsed as such. In HTML, if your browser comes across a tag that it doesn't understand, then it skips it, and there's no harm done. The HTML language is designed to behave this way. SQL is not. In SQL, if your DBMS comes across a SQL command that it cannot handle, it must immediately abort. The problem is that MySQL doesn't. So if you're using MyISAM tables, and you issue a START TRANSACTION command, MySQL will happily print "OK" and continue on its merry way. Same if you try to define a foreign key, etc. This is not desirable behavior; it is clearly a design flaw. Anal-retentive error checking is absolutely appropriate for a DBMS.
When I read "MySQL attempts to make reasonable assumptions in situations where different clients may have varying ways of making a query", I nearly fell out of my chair. MySQL's handling of default values and NULLs is so incorrect that it's not even funny. MySQL seems confused about the value 0, the empty string "", the current timestamp and a NULL (which is not a value). Again, see the MySQL Gotchas page for examples. Its habit of (silently and automatically) creating default values for every column effectively "castrates" any NOT NULL constraint. This behavior also makes writing portable applications very difficult - since no other DBMS takes such liberties with its inputs. Of course, other DBMS also don't lie about performing operations...
I'll end with one final example of silent error passing in MySQL 4. Say you're try to create an InnoDB table. If you have "skip-innodb" enabled in my.cnf, then MySQL 4 can't create an InnoDB table. But, if you do a CREATE TABLE foo(blah) TYPE=InnoDB; MySQL won't bother to print an error message. It won't tell you "Hey, I can't create an InnoDB table, b/c you disabled support." No, it will instead print "OK" and then go and create a MyISAM table. So, you asked to get a table with one set of behaviors, but you ended up getting one with entirely different characteristics. I encountered this bug at work a few months ago on a MySQL database I inherited from a previous "DBA": I started wondering why certain operations weren't failing, and eventually traced down the problem. (This, by the way, is yet more evidence of MySQL's questionable design of having different table types which behave differently. The hallmark of relational databases was supposed to be independence from physical storage methods; MySQL has gone and reintroduced these dependencies).
You started this thread by saying that you question what niggling problems remain in PostgreSQL because some random Slashdot post mad
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Happy New Year to you too!
I think your continued posting just demonstrates my original point, which was that there are most definitely religious zealots out there who seem to hate MySQL with quite amazing fervor, simply because it doesn't conform to their own notions of relational purity. Thanks for demonstrating this so effectively!
You point up quite a few "gotchas" in MySQL that do, I admit, seem to be bugs. Whether they are active design flaws or simply outstanding bugs, I have no idea. Fact is, I have never had to dig that deep into the product, simply because I have never had any such problems with it! Believe me, if the thing was as rife with errors and evil as you seem to be suggesting, then I (and millions of other people) would never use it. If MySQL exhibits so many showstoppers, then why on earth would companies like Yahoo!, Sabre, Cox Communications, the Associated Press and NASA all using it? Of course, you'll reply, these companies aren't using MySQL for anything critical. Truth is, I just took five seconds to drag those names off the MySQL website - I have no idea what they are actually using it for. But why would they bother using it at all if it was so crappy? Answer: It's not really that crappy. It's a pretty good database, with flaws, admittedly, but it does work very well for many, many applications. I don't doubt that you could probably pick any product apart and come up with a similar set of "gotchas" to the famous "MySQL Gotchas" page. I think the fact that this page exists at all simply further demonstrates the level of religious, righteous rage that seems to be directed against it... listen, if I was coming into this cold, with no knowledge of MySQL, then it might give me some pause to hear about the Gotchas. But I have the advantage of having actually used the thing for the last four years, on a daily basis, and thus I am in a good position to say with some degree of certainty that MySQL does actually work very, very well.
I really feel sorry for you that you apparently feel the need to put down MySQL at every opportunity. I can see from your other recent posts (here's one, and another, and yet another) that you seem to actually have something of a crusade going on here. Ok, so I've posted quite a bit recently too, but it's not quite the same - I am posting in relation to a thread which I explicitly started. You seem to delight in digging around to find anything that anyone says in relation to MySQL and immediately jumping in to slam it.
Let's consider what we are both saying here. I am simply saying that MySQL is not a heap of crap, based on my own experience of years and the fact that millions of other people use this product very successfully. I'm not trying to say anything negative about anything else, just attempting to offset the bile that spews forth from people like you. You are trying to say that MySQL is in fact a steaming heap of faeces, due to "all these things that it does wrong and all these errors that it doesn't report and all these features that it is missing". Consider what you're saying here! Isn't it even a tiny, tiny bit likely that you're just being a little bit too purist about all this? Can't you accept the remote possibility that, just perhaps, you've gone somewhat overboard in your condemnation of MySQL? No? Oh well.
Ok, so I tried to finish this off in a pleasant way in my previous post, but I guess that didn't work, so we have to resign ourselves to yet another reiteration of MySQL's shortcomings and reasons why there's no possible way that all those millions of people could actually be using MySQL in their applications and products - why, we must all simply be mistaken! It must all be a huge mirage, put out by the evil overlords at MySQL AB! Shame on us all for using such a crappy database, and shame on me
Re:For all the PostgreSQL zealots out there...
by
Cajal
·
· Score: 1
It is you, sir, who insist on making this a religious argument, not I.
I never said MySQL was "evil," or referred to the employees of MySQL AB as "evil overlords." All I have said (many, many, many times) is that MySQL has many flaws. These flaws, taken together, are so severe that it's not a good idea to use it. It's great that it's easy to use and setup, but if it doesn't protect your data, then it's not worth using.
Secondly, as I have said before, just because a lot of people use MySQL doesn't mean that it's a good product. Lots of people use Windows, lots of people smoke cigarettes, lots of people do lots of unwise things. It isn't a valid line of argument to say "lots of people do X, therefore X is acceptable."
Further, as I have said before, the fact that you have never seen MySQL print an error message does not mean that it's a good product. MySQL tries very very hard to never print an error message. It will even lie to the user before it will print an error message. If you've somehow managed to avoid being affected by the issues outlined on the MySQL Gotchas page, good for you. But it's been my experience, and that of a great many other people (not all of whom use PostgreSQL) that concocting workarounds to avoid the Gotchas is not worth it.
And I never said that "here's no possible way that all those millions of people could actually be using MySQL in their applications and products" - only that it's is monumentally unwise to do so. That so many do is only indicative of the poor state of relational database education in the industry. And before you again accuse me of being some elitist snob in my ivory tower of relational purity, realize that I have had to deal with far too many clueless MySQL "DBAs" who eventually end up asking me stupid questions like "do primary keys have to be unique" (that is a real world example). With uninformed admins like this, it's no wonder that so many are so easily duped by MySQL AB's marketing campaign against "advanced" features (which are considered basic features in every other DBMS, even ones like SQL Lite).
This isn't some puritanical stance based on "religious" beliefs. This is how relational databases are supposed to work. See work by E.F. Codd, Hugh Darwen, Chris Date or Fabian Pascal for more information. In particular, I recommend Fabian Pascal's book _Practical Issues in Database Management_. Yes, it's possible to setup a database without referential integrity or transactions. But doing so is asking for trouble, and it's been my experience that nearly every database done so will eventually have serious problems because of it. Again, that's a real-world concern, not some abstract, academic one.
I have no ire with MySQL users, nor do I think they are all stupid or evil. Nor do I claim that all PostgreSQL users are wonderful people. My problem is with the undereducated masses who think MySQL is the greatest thing since sliced bread. I have no problem with other DBMSes. My ire is reserved for MySQL, since I've been forced to deal with its brokenness far too much.
No doubt you will post yet another post claiming that I'm some rabid PostgreSQL "righteous religious" zealot who foams at the mouth at the mere mention of MySQL. Do as you wish. Your blather will henceforth fall on deaf ears.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Hah, I knew you couldn't resist one last shot! Attaboy! Hey, here's an idea: How about we save people a lot of time and just summarize the next few posts:
Cajal: MySQL sucks! ngunton: Nuh uh! Cajal: Uh huh! ngunton: Does not! Cajal: Does too! ngunton: You elitist, arrogant snob! Cajal: You ignorant MySQL weenie! (ad nauseam)
Um, do I have that about right?
(sorry for putting words in your mouth, dramatic license, I'm sure you'll understand)
We've both stated our positions on this matter, dude. Let's give it a rest now, eh?
Relax, move on, try to let go of your hatred. It's really not healthy (sorry, couldn't resist one... last... barb...
(fade, to evil laughter)
Re:For all the PostgreSQL zealots out there...
by
Sxooter
·
· Score: 1
I would say that there are zealots on BOTH sides, and painting all the supporters of either product as zealots is insulting. so, this thread started with an insult, the z word, and some people took it a little personally, which is understandable.
Your last paragraph, where you say:
As for the 8k row limits, so, in this regard, MySQL was in fact *better* than the big databases such as MSSQL and Oracle? So why, instead of complementing MySQL for this accomplishment do we slam it as a toy database?
shows the MySQL crowd's tendency to major in minors and minor in majors. The most important part of a transactional, SQL spec compliant database is that you can wrap all your work up in transactions, and be sure that "all or nothing" goes through, not partial updates that leave your data in an inconsistent state.
I.e. trumpeting >8k row size as an advantage while still not having transactions (i.e. the past versions of MySQL, pre-innodb) is like selling a car based on the wide choice of colors it is available it. It's not an overly important point for a database, whose primary responsibility is to reliably store related data in a method that ensures the integrity of your data.
Good exchange, hope to see you around in the future...
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:For all the PostgreSQL zealots out there...
by
Sxooter
·
· Score: 1
No, here's a more accurate one:
ngunton: MySQL's many bugs aren't a problem. It works fine. I've never seen data loss, so it must not happen. Cajal: well, actually, there are problems here they are: (list of problems follows) ngunton: Nu uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you. Cajal: But, here's the list (repeat list) ngunton: Nuh uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you
repeat until dizzy.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
Actually, I was trying to wrap up a seemingly endless thread in a slightly humorous way. But since you insist on keeping this thing alive in a way that is clearly inflammatory, let's take a closer look at this "loser" of a database called MySQL.
It's in heavy use on millions of installations around the world. NEC is using MySQL to power its Global Navigator Management Information System. For the sixth year running, the readers of Linux Journal voted MySQL "best database". Sabre uses MySQL to power its Air Shopping products, mission-critical enterprise services that "conduct online travel searches for Sabre Holdings customers such as Travelocity, airlines and travel agents worldwide.". Slashdot uses MySQL. Yahoo!'s Jeremy Zawodney seems to think that MySQL rocks. Yes, all these links are dredged up from the MySQL AB site. No, it's not propaganda - it's real companies, using MySQL to do real work. Simple as that. Sorry if this interferes with anybody's purist views on just how a database should be - I am not denying that MySQL has its share of bugs and design flaws, but my original point (and one that seems totally lost on the religious fundamentalists) is that the story is not that black and white. MySQL works very, very well as a real database, in many, many applications. No doubt PostgreSQL does too. Hopefully both will get better... but I am truly sick and tired of these people dragging out the same old list of "gotchas" for MySQL (which you could, let's face it, build for *any* product if you were just plain obsessive enough about it - which is apparently the case for the anti-MySQL database fundamentalists).
I think the main problem I have is that while the fundamentalists can point to a list of bugs and gotchas, all I can point to is a feature list that just keeps getting better (transactions, subselects and all the rest is now in there), and a set of very successful, large, competent companies, and millions of other installations that work reliably all day, every day. It's not as dramatic to say "it works" as it is to point up problems. MySQL is clearly being actively developed, and no matter what people say about "problems" with error codes (issues which I have never experienced myself, in four years of heavy, daily use) - no matter what the fundamentalists rant about, it's clear that MySQL works extremely well. Go tell Yahoo!, NEC, Sabre, Slashdot, and all the millions of other users that it's "not a real database". Go tell them that they are ignorant and clueless about what a database should be. Whatever.
Meantime, why not try getting a life.
Re:For all the PostgreSQL zealots out there...
by
Sxooter
·
· Score: 1
No matter what you were trying to do, what you did was to characterize the postings Cajal as a flame (i.e. MySQL SUCKS!)
In fact he carefully pointed out the areas where MySQL is strong, as well as the areas it is weak, and why he would or would not recommend it.
Each time he did this, you kept taking it personally, and responding with emotion laden, logically fallacious arguments that proved no point other than the fact that you take these things far too personally.
Keep in mind, in this same thread, I also pointed out that MySQL has jobs for which it is particularly well suited (content management, report generation, etc...)
Cajal was being characterized as attacking MySQL in your post, which he most certainly did not do.
The point of my post, which apparently went straight over your head, was that the argument had gone far different than you had portrayed it, and that in fact while Cajal was being quite civilized and presenting his points in a non-emotional and non-insulting manner, you, sir (or madam) insisted on treating it like a flame fest.
Your response showing how many place MySQL works is an emotional appeal used to try and win a logical argument, and it just doesn't work.
The fact that it can be used for contact management, shopping carts, and content management in no way obviates the obvious flaws it does have, it simply means that for those tasks, those flaws are not a show stopper, or maybe even work for it, since they simplify the code path and allow it to run faster.
The fact is, Cajal brought up cogent points, and your constant response to him was "Stop flaming me, MySQL does NOT suck, nuh uh, I'm not gonna listen" and so on. I use Postgresql and MySQL for different projects, and know the weaknesses of both. There are some problems I would recommend one or the other to solve, and many that they overlap on. Each has its strenghs and weaknesses, and to just run around saying "MySQL is the best because it just is" accomplishes nothing. If you want to have a solid logical argument, feel free to start one. So far, you've done little but to insult those who have a differing view point by claiming they are attacking you and your favorite database in the whole world.
Don't take this stuff so personally. In a hundred years, we'll both be dead ya know.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 1
You know, it's quite funny how people will "spin" the truth to suit their own position... my only point, all along, has been that MySQL does work. Very well. Just about the only thing that people like Cajal seem to be able to do is to go out of their way to say that it's a toy and good for nothing much. This leaves me philosophizing about the possible causes for such attitudes.
I can only guess that such animosity exists because some people have chosen to use one tool, they have some knowledge or education about relational theory, and so they feel very threatened when they find out that some other tool, which doesn't adhere to all of their proudly held theoretical beliefs, is much, much more popular and widely used... why, this is a threat to their world view. It might mean that their rigid, fundamentalist, purist approach to the world might be, well, misguided to say the least. No, MySQL doesn't have all the bells and whistles that some other databases do. I freely admit this. But (and this is the part that you apparently seem unable to grasp) all I am saying is that it is an extremely capable database for many, many tasks. What more is there to say, really? It works very well. Large companies use it extensively. I have used it extensively for over four years now. I've had absolutely no problems with it. So I find it offensive when people keep popping up whenever MySQL is mentioned, to denigrate it as a toy, not a "real" database, simply an SQL interface to the flat file system, etc. I find it tiresome that these zealots (there is no other word to describe them, really) find it necessary to slam MySQL at every opportunity. They don't just argue the relative merits, no, they actively slam it as being not worth using at all. This is the main reason I call them zealots and religious extremists. Such people classicly take extreme positions that exclude all other viewpoints, and moreover when challenged or disputed they become rather violent (if only in print) about it.
I believe (and this is just a theory) that these people have a particular kind of rigid, ordered techie mind that requires order in all things. If they find out that some tool does not follow all the theoretical constraints of the relational model, then they find this something akin to sacrilege. These people, in effect, have the technical equivalent of a religious fundamentalist view of the world. They cannot countenance for a second the possibility that it's not actually always necessary for a relational database to support stored procedures, or subselects, or even transactions. No, if it doesn't adhere to their equivalent of the Holy Bible of Codd, then it is an abomination and must be cast out. The parallels to a religious viewpoint here are really interesting - you see the same aggressive criticism from the anti-MySQL crowd that you see from the religious fundamentalists of any religion toward the less strict denominations.
You might argue that we're talking about technical, solid, logical issues here rather than amorphous religious beliefs, but really we're not. It's obvious to me from personal experience that MySQL works perfectly well as a database, in fact it is quite a wonderful tool. Simple, fast, extensible, widely supported and growing in features. It now supports transactions, and the latest versions support subselects and stored procedures. This is all great to have - but it was never necessary in order for MySQL to be a truly useful database tool. How can you not read my previous post, with all these companies and projects who use MySQL for large projects, and still say that it's "not a real database"? Why on earth would NEC, Sabre, Slashdot, Yahoo! and all the users who voted for it on Linux Journal (for six years running!), the millions of other users - why would all of these use such a thing if it was so crap? You (and Cajal) in turn actually refuse to address this inconvenient fact. You simply ignore it, and tell me I'm being "irrational". How bizarre.
Who'd have thought, even this lousy bait attracted some nice Insightful catch...
Moderators these days...
Not for general consumption
by
EvilNutSack
·
· Score: 0, Offtopic
...Phew! After today's turkey I don't think I could eat anything else.
-- --
Idiot moderators!
by
Anonymous Coward
·
· Score: 0
Why in the hell was that post marked insightful? Older versions of MySQL have all of those things. Why in the hell was a bold-face lie like that moderated upward? This site just gets worse and worse. There are too many idiots with moderator points that moderate good posts downward and trolls upward. I've seen two trolls this week alone that had +5's. Why?
Re:Idiot moderators!
by
Anonymous Coward
·
· Score: 0
Because in any given group of people, the majority of them are idiots. That's why. Slashdot is no exception, unfortunately.
I don't care what anyone else says! It's MySQL 5.0 and we're running away together! You never understand me! Maybe no one else will ever understand us either, but alpha or not, we're n love!
-- -- 'The' Lord and Master Bitman On High, Master Of All
Re:great, now all we need is...
by
Pathwalker
·
· Score: 1
Is this version ACID-complaint already? How does it compare with PostgresSQL performance-, consistency- and security-wise? Thanks. I am going to start a new database soon and maybe I'll change my mind in favour of MySQL if this new version satisfies the ACID principles.
-- Sincerely, Pan Tarhei Hosé, PhD. "Homo sum et cogito ergo odi profanum vulgus et libido."
A good CMS that works with PostgreSQL
by
dskoll
·
· Score: 1
Check out Drupal. Although primarily developed for MySQL, it does work with PostgreSQL.
Re:Discussion of MySQL should include MySQL gotcha
by
Anonymous Coward
·
· Score: 0
Re:MySQL and PHP legalities
by
Anonymous Coward
·
· Score: 0
which is a fucking shitty solution. i worked on a clients server a few months ago and had to comppile in mck support. it was a p2/733 single processor web server. it took nearly over 4 hours to get php recomiled, adding mck support properly. the compile itself took 2 hours and dumped out on a stupid error the first time. now every time redhat pushes a new update for php, we have to block that, myssql and apache and wwait until we can get a new php compiled. what a bunch of shit. someone needs to figure this out because bullshit like this is what will make open source & free software not worth the price of admission. these licensing incompatabilities and all the fucked up games that go with them are a drag on the community.
cry
by
Anonymous Coward
·
· Score: 0
sometimes i dream that i am on the banks of a river at night, looking at a crowd of small boats all going downstream. each little boat has a little person on it and they are holding a stalk with a glowing light. they see me on the banks with a broken stalk at my feet. ignoring me they press on. i don't feel sad at all. i take for granted my solitude at the banks of the river. the thought of one day seeing another like me, with their broken light taps an emotional reserve i didn't think i had/bpr
Re:Discussion of MySQL should include MySQL gotcha
by
Zontar+The+Mindless
·
· Score: 1
Please mod parent down as a troll -- this is a dupe of a post in the last MySQL story thread (even including the "Don't read this..." section). (And it's redundant to boot, given that we've already had several links to sql-info.de's MySQL Gotchas in this discussion.)
The technique is straight out of the AntiSlash Karma Whoring How-To -- don't let this jerk get away with it.
-- Il n'y a pas de Planet B.
I wanted the graphic effect of the quirkiness.
by
Futurepower(R)
·
· Score: 1
Yes, and 99% of those reading the comments would not realize how long is the list. The graphic effect of seeing all the areas of quirkiness is informative.
Recognize MySQL's quirkiness.
by
Anonymous Coward
·
· Score: 0
It is easy for me to agree with you that you are mindless, Zontar. So what if it is the same post? It is extremely important in any discussion of MySQL to realize how quirky it is.
Quirkiness is a major problem with MySQL. Once you get started with non-standard implementation, you travel down a path from which it is difficult to return.
when the hell will 4.1.1 even be released as BETA???? I've been waiting a year and it's still alpha, still not close to a stable production version yet.
Re:Discussion of MySQL should include MySQL gotcha
by
Sxooter
·
· Score: 1
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.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
You wouldn't have those problelms...
by
Anonymous Coward
·
· Score: 0
if you were using Postgresql.
Remember, Postgresql is a MOVING target.
by
Sxooter
·
· Score: 2, Informative
Congrats on being curious enough to look.
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are: Point in Time Recovery Sub transactions Very low I/O contention vacuuming. Win32 native port Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial strength synchronous replication (.org uses postgresql with this solution), GiST indexes, ssl/ssh connections, many new procedural languages (R, PHP, python, java), and most importantly, performance improvements.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Re:why this matters?
by
Anonymous Coward
·
· Score: 0
Yo, asshole. Vacuum is no longer blocking, and the new autovacuum daemon means I can just "set and forget" the database. Maybe you should stop talking about the problems Postgresql had 3 or so years ago, eh?
FYI, I ran a test the other night, with 50 simultaneous transactions running 250,000 bank transactions one at a time each. That's 10,000,000 transactions. It ran in ~ 12.5 hours, at a rate of 220 transactions a second. Even our Oracle servers have a hard time with that kind of sustained load. MySQL would crash and burn long before morning came along.
Maybe you should actually TEST the newest flavor of Postgresql before making yourself look like the clueless idiot you obviously are. Oh, that would actually take effort and time, and you don't have any of that left over after all the time you spend blowing sunshine up your own ass.
To anyone who complains about speed: (1) Does RDBMS performance actually affect your application, or does the bottleneck lie elsewhere? (2) Do you really have the numbers for your application behavior, or are you just guessing? (3) Did you put some minimal informed effort into making the RDBMS perform well, or at least as much effort as you put into the alternative? A good place to start for a postgresql performance problem (hint, hint) would be a detailed description of the problem on pgsql-general.
-- Social scientists are inspired by theories; scientists are humbled by facts.
>You can do a lot of stuff in MySQL by working around missing features. But WHY????
Because MySQL permissions are easier to deal with? Doing stuff like changing the owner of a database in postgres is.. annoying to say the least. How about out of the box replication? (I haven't had a good look at the replication options for postgres to be honest).
I'm sure there are things that postgres does that mysql doesn't, or things it does better. However the plain fact is a lot of people don't need those things, and MySQL is a lot easier to deal with in some other important regards. This is one big reason why more webhosts offer MySQL than Postgres databases to their customers (or charge more to deal with postgres)
Re:Discussion of MySQL should include MySQL gotcha
by
Zontar+The+Mindless
·
· Score: 1
> Simply because it's been posted to other threads does not make it redundant
No, but the fact that those links had been posted to this discussion several times already does. Thus,
-1 Redundant.
> and simply because it bothers you that someone would point out flaws in MySQL does not make it flame bait.
That's not what I said. This is not a case of "You dissed my DB so I hate you forever" crap, okay? Nor am I knocking the MySQL Gotchas, other than that they're formulated in such a way as to make the originator's prejudices readily apparent, and he tries to make it sound like MySQL AB don't tell you about these things, when in fact, you'd know this stuff if you had RTFM. But it's still a good resource if you keep that caveat in mind.
When somebody puts that kind of stuff in a post to make it obvious that they've done it to defeat the lameless filter, and copy/paste it word-for-word from another thread into this one, and offer absolutely nothing new to the conversation in the process... If it looks like a troll, and acts like a troll, it's a troll. Like I said, it's straight out of the Karma Whoring How-To. Therefore,
-1 Troll.
I haven't bothered to check to see whther or not he copied/pasted his own post, but if it originated with someone else, that'd be
-1 Plagiarism
as well.
> It's also not a troll. Everything in that post is TRUE.
Trolling has nothing to do with whether or not something is true. There is such a thing as malicious honesty, and this guy's guilty of it IMNSHO.
> 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...
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
I don't visit pgSQL threads dumping on postgres, and you'd think some people would be mature enough to return the favour, but I guess not.
My only complaints against PG are:
1. Trying to get it running on Windows is a PITA. (One of the reasons I prefer MySQL is that it is brain-dead easy to install on Linux, Windows, Mac OS X, and about a dozen other platforms, and it runs almost identically on all of them. Given that I work on all three of the OSes I named, that's a very important issue to me.)
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
BTW, I've not been afraid to go against the MySQL AB "party line" -- in print -- when I thought it was wrong or misleading. It's not made them particularly happy with me at times, either, but so it goes. Being dogmatic tends not to do one's readers any favours.
-- Il n'y a pas de Planet B.
mysql sub select nested queries and stored proc
by
chrisranjana.com
·
· Score: 1
"basic support for SQL-99 stored procedures."
sounds great !
it is about time this happened !
MySQL is a lot easier to deal with in some other important regards
What other regards? This is a serious question, because I don't think the developers always know. They know everyone wants easier-to-use replication (there are some good solutions out there, but nothing is really "out of the box"). I suppose that changing the owner of a database counts, but I don't think I've ever had to do that. I'll try it out and maybe try to get that fixed.
So, for the benefit of the success of PostgreSQL, what is your wishlist for its improvements?
-- Social scientists are inspired by theories; scientists are humbled by facts.
Platform makes a big difference to performance... we find same query is about six times slower on Solaris 8 than our notionally similar setup on Red Hat 8. (Yes, we used the Postgresql-recommended kernel parameters.)
-- "Don't belong. Never join. Think for yourself. Peace."
V.Stone, Microsoft Corporation
I learned (and still use) mysql because of its documentation. The manual is huge and comprehensive - single sided, the docs for 3.x take up a 3" binder. These docs (and surprisingly, a book on database programming in vbscript, of all things) are what taught me SQL.
I wanted to switch to postgresql, but at the time (about a year and a half ago) the docs just weren't there for it. I like a nice manual, a la freebsd or mysql. If this has changed, I'd switch to postgresql in a minute.
'Course, for what I (and many others) do, mysql is perfectly suitable. I write web-based databases in PHP (mostly) for small businesses to track customers and products and such. The features postgresql has over mysql are overkill for this sort of work (AFAICT, as I'm not a database guru).
-- Those who can't do, teach.
Those who can't teach either, do tech support.
Stored Procedures? Which language?
by
leandrod
·
· Score: 1
What does it mean 'ISO SQL:1999-style stored procedures'? Java, PL/SQL, SQL/PSM?
Stored procedures are a mess, with a de facto ill-defined Java standard trend, a de jure SQL/PSM standard supported by IBM DB2 and not much else, and a proprietary, non-portable PL/SQL supported by Oracle and PostgreSQL.
But anyway I won't consider MySQL when I have PostgreSQL with a much sounder, even if not perfect, approach to fundamentals.
-- Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Did they remove...
by
Anonymous Coward
·
· Score: 0
... the goddamn GPL from the client libraries? Or are they still doing tricks?
Re:Stored Procedures? Which language?
by
Anonymous Coward
·
· Score: 0
> But anyway I won't consider MySQL when I have PostgreSQL with a much sounder, even if not perfect, approach to fundamentals.
> DBA, SysAdmin looking for a job!
Gosh, I know MySQL and I've got plenty of work using it. Glad to see your skills with the "sounder approach" are so marketable.
backing up your replication server
by
KyleCordes
·
· Score: 1
[backing up your replication server? That's a pathetic solution]
In a way, it's pathetic that this is the only way to do it; in another direction, though, it's a very smart thing to move any activity that doesn't need to happen on the primary (bottleneck) server to a secondary server instead.
A similar practice is commonplace in the MS SQL Server world, running lengthly reporting queries on a secondary reporting database instead of on the primary.
Re:backing up your replication server
by
kpharmer
·
· Score: 1
> In a way, it's pathetic that this is the only way to do it; in another direction, though, it's a very smart thing to move any activity > that doesn't need to happen on the primary (bottleneck) server to a secondary server instead.
Sure - but in the case of backups - how do you perform a restore based off a replicated database - and then reapply all the missing transactions? I don't think it can be done. Which means that these are the equivilent of offline backups, not online as far as recovery goes (though online as far as availability goes I suppose).
> A similar practice is commonplace in the MS SQL Server world, running lengthly reporting queries on a secondary reporting database > instead of on the primary.
Yep, this isn't too expensive - aside from the licenses and hardware. I'd typically recommend folks to use light ETL and convert the data in transit. That'll give you better performance and accuracy than you can get out of reporting on an oltp model.
Re:Discussion of MySQL should include MySQL gotcha
by
Sxooter
·
· Score: 2, Interesting
Cool, I get your point on most of what you say, but, this:
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
doesn't fix all the problems. It fixes quite a few, but the ones that are left are still pretty nasty, imnsho.
Further, about Postgresql, you said:
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
I call shenanigans. While the Postgresql docs are not aimed at the beginner, as someone who already understands database theory, I found them quite good. I didn't need someone to point out what a foreign key was or what it could do, only how Postgresql implemented it. While the MySQL docs are great for beginners, they are actually pretty damned cumbersome for people with experience. Also, the Postgresql docs have had a lot of input in the last year or so, so you might want to look at them again.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
How do you know when it's done?
by
Crag
·
· Score: 1
Despite what ivory tower CS folks would like us to believe, it's not practical to apply proofs to all programming to guarentee correct operation. Godel might even argue that it's impossible for any non-trivial algorithem to be bug free. Any program more complex than Freecell can only approach "stable release quality" asymtotically. To achieve what you request, versions would have to be assigned as 4.9, 4.99, 4.999, 4.9999,... because there's always one more bug.
The alternative would be to re-number versions as they reveal their stability: "Ok, that last 5.0? That was actually 4.9.100, this one is the real 5.0." This would undermine the real purpose of the version number, which is to uniquely identify the VERSION of something.
The version number cannot and should not be used to ascertain the quality of that version. There's no substitute for actually researching or testing the performance of the product to see if it's what you want.
I think the best one around is PgAdmin III at http://www.pgadmin.org
I don't use it much, but it looks very nice and is easy to work with for the little stuff that I have done. It's also cross platform, and I've used it on windows and linux.
-- Social scientists are inspired by theories; scientists are humbled by facts.
Just finished upgrading...
by
Phil+John
·
· Score: 1
...all my mission critical servers that run MySQL, let the testing commence baybee!;o)
Re:Great Try BerklyDB
by
Anonymous Coward
·
· Score: 0
Go with BerklyDB if you are interested in ACID. The two most popular things to come out of Berkly were ACID and UNIX. Coincidence? I think not.
Re:MySQL and PHP legalities
by
aztracker1
·
· Score: 1
Actually, Windows, is one of the reasons *I* use mysql over postgre... ever tried running postgre on windows? last time I tried, it required a hammer and chissel to make it work.
Now, as for PHP on windows, it's not much harder than running the installer (although win2003 server makes it a little harder)... as for PHP+MySQL, the precompiled binaries have the support built in, even without the extension.dll, so get your facts straight. MySQL is equally easy to install, and the 4.0 runs pretty rock solid.. and does what I need, which is push a *LOT* of data fast...
I am writing ASP.Net applications that run under Windows Server 2003 Web Edition, and connect to a db server running Suse 9.0 + MySQL 4.0.x and it runs like a bat outta hell.
before I get blasted for having windows as my choice of OS for web stuff, is simply ASP.Net rocks... and Mono's (mod_mono) simply isn't stable, and proven enough yet... so, I compomised, I use MS for the webserver, which is a pretty nice price point on the web edition, and connect to MySQL, which means I can test on windows, and deploy to live... pretty much best of both worlds.. beyond that 99.99% of anything I have done to this point runs under mono, which has a more mature MySql Driver (ByteFx) available than the Postgre driver at this time, another reason for mysql.
now, if postgre now has an installer, and runs pretty straight forward under windows (haven't had any issues with mysql under windows), let me know...
Note that there has been a lot of work in the last year to get Postgresql running faster on Solaris, including several fixes to Solaris itself, such as it's (Solaris') very very (very very???) slow qsort with lots of equal keys being replaced by BSD's qsort.
You might want to try it again, and report back to the pgsql-performance list to see if they can get you some help.
--
--- It is not the things we do which we regret the most, but the things which we don't do.
Slashdot Mirror
This means that whenever it is stable and ready for production, it is going to have a random version number. Not the smartest practice.
.0 and not .rnd()
It would help if the major stable releases were
-Charles
Learning HOW to think is more important than learning WHAT to think.
That's disappointing.
I've been wanting sub-queries and stored procedures for a couple of years now.
This is sweet, professional level db programming for free might have an incredible impact on the web
Don't forget that most of your favorite sites probably use MySQL.
Will code a sig generator for food
The Apache 2.0.x series has seemed similar. They weren't production ready until the 2.x.3?'s.
Have they fixed the most serious bug from the 4.x line yet? This makes MySQL versions greater than 3.x utterly useless for many people.
;)
I realize and reaffirm that it is wholly their right to license their software however they like, but would it really be so awful for them to make the client library LGPL?
Ah, well... just another reason to use a better database instead.
The Free desktop that Just Works
Now all it needs is (proper!) transactions, rollbacks and subselects, and then it might be suitable for a production environment.
Who the hell is coding and releasing new versions on Christmas Day? Take a break!!
And who is reading f$%king slashdot on Christmas Day too??
Oh wait.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
This rant brought to you by a Squadron of Attack Kittens.
I've been using MySQL 4.1 on a live server (with customers) for two or three months now. I basically wanted subqueries at the time, and so I just upgraded the box with disregard for everyone else ;-) Luckily everything worked great! There's a little quirk with Unicode if you play with the character type settings on certain fields (as long as you stay away from Unicode you'll be more than okay). I also occasionally have the server die when given certain lengthy queries, but it comes straight back, and gets on with things.
So, no, it's hardly Oracle, but even MySQL's alpha stuff seems to be reasonably usable, as long as you aren't doing anything too serious. And, as any database expert will tell you, you probably aren't going to be using MySQL for anything that serious anyway. Nice work MySQL.. I'll spare my users from an immediate upgrade to MySQL 5 however.. for now!!
mogorific carpentry experiments
PostgreSQL chockes even on small database files. Once every 24 hours.... - vacuuming. Very cute.
Maybe I'm just old school but the whole idea of making even more variables case insensitive is for me just complicating the syntax even more And even though we're all trying to make our programming languages more "human like" I don't think that the base ideas of programming have reached the point where those steps should be giving that kind of attention.
This story will of course bring out all the PostgreSQL trolls, But really, there are very few trolls against MySQL that hold much water, anymore. The response to this post (if there are any) will go like this: A bulleted list of general gripes with nothing to back them up. Funny thing is, these trolls are quite willing to pass off on the faults of their favorite dB by downplaying the importance of a particular lacked feature, or that some shortcoming really doesn't have much effect in "real-world" use. Like many fine products, MySQL does not try to be all things to all people, unlike the code-bloat MS-SQL and Oracle.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Mensa member, beware of the high IQ
It's so kind of you to hide that fact in the body of your message. Just kidding.
It is quite interesting what they are doing with MySQL-Max with seems to be their enterprise solution. They teamed up with SAP DB, an open source database technology that SAP bought from Software AG to tease Oracle a bit. It is based on Adabas D a commercial database that has a "oracle compatibly mode" via ODBC.
It is quite interesting to see a mixture of SAP DB and MySQL united in MySQL-MAX. (Infoworld article)
MySQL supports full text indexing and search as well. And I bet it's much faster than PostgreSQL's.
If you wrote this yourself, I love you.
If you stole it from someone else, I love you even more.
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using. MySQL 4.x has replciation between master adn slave databases. Using replication you can easily do backups without taking down your live server. MySQL 4.1.1 Does subqueries. MySQL 5 should be where we get database clustering.
Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
hahahahahhaha
mssql
hahhahahahahahahaha
o man, good one!
Perhaps the people using MySQL don't use those features you mention. Maybe they need to run a native Windows (not Cygwin) version or another platform that isn't supported by PostgreSQL. Could be they have some app they want to use that comes out of the box setup to use MySQL.
I use them both, and I won't say I don't think Postgres is better, but there are times when MySQL works just as well.
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether .., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
2.3 (released) -> 2.3.1a -> 2.3.1b -> 2.3.1 (released) -> 2.4a -> 2.4.b -> 2.4.1a -> 2.4.2a -> 2.4.3a -> 2.4.3b -> 2.4.4a -> 2.4.5a -> 2.4.5b -> 2.4.5 (released)
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
make install -not war
I've just skimmed over the comments, and seen that a few people mention that MySQL is not yet ready for use on a critical server in the real world.
:)
Now, I'm no database expert at all, and I've only ever used MySQL for databases. But as far as I know, slashdot itself runs on MySQL (supporting evidence?). Now, this is a site that gets a hojillion comments per article, several articles per day, with enough viewers to crush lesser sites at will. Surely this suggests that MySQL must be ready for "mission critical" use, at least in some circumstances.
Just an observation from a database newbie.
Clever name.
Wow.
I mean, wow.
From that comparison, I'll switch my shop from a fully functional PostgreSQL installation to MySQL. For reference, I'll point to post #7808905 on slashdot. Save some money instead of hiring a consultant.
Ass.
Did it fix any of the MySQL Gotchas?
If only I could come up with a good sig
Perhaps the people using MySQL don't use those features you mention.
You can do a lot of stuff in MySQL by working around missing features. But WHY???? There are free alternatives out there that don't have key missing features, and don't force you to write these work arounds.
Slashdotters get so excited over an improvement in any technology, they'd drool over an improvement of the steam engine.
This comment is printed on 100% recycled electrons.
Now I know your IP bitch. You'll never been safe now. Get ready for the pumpkin!
The problem is that the licences don't allow you to distribute MySQL and a MySQL-enabled PHP together, hence for example Red Hat is still including MySQL 3.x with their newer offerings like Fedora.
There is however no problem with you downloading MySQL from mysql.com and PHP from php.net, configuring php to use your local MySQL copy and then running the two together. At least for Linux users this is no problem, since it's literally a 3 minute operation. It's on Windows it gets ugly when you have to recompile PHP, how many windows users have (or want) a compiler around?
this is so far wrong it is laughable.
PHP "used" to compile/distribute automatically with MySQL support installed by default. That means the libraries would be embedded into distributed binaries.
All PHP had to do was remove the "default" libraries, yet still leave MySQL installation as an option (--with-mysql=/path/to/mysql), and there are no licensing issues.
MySQL is now GPL, so you cannot include MySQL code (embedded db) in a product without continuing the GPL.
Also, the PHP group was trying to work this out with MySQL prior to the PHP 5 beta releases, so that PHP users would still have MySQL by default.
- only AC because my acct. doesn't work.
- httpdotcom (m. geier)
And it is not as slow as postgres either. I love postgres, I love the features but the performance under heavy loads plainly sucks.
Got Code?
"but the performance under heavy loads plainly sucks."
What are you talking about? PostgreSQL shines under heavy loads and large databases. It's MySQL who chokes on heavy loads and large databases.
Get a clue.
Can a single table hold at least 100GB of data, and still have fast read-write access, say, less than 30ms for both a SELECT with index and INSERT?
How much time does it take to do a backup of a 100GB database?
Failover support: when a slave takes over, how long does it take to restore the master and switch back for a 100GB database?
Are views or foreign keys with constraints supported?
Does stored procedure increase performance by precompilation?
Welcome to Slashdot. Say anything bad about Linux, MySQL, etc and you'll be modded as a troll. On the flip side, say anything good about BSD, Microsoft, etc and you'll be modded as a troll.
How did this get modded up so high? This has been hashed over before and it's not illegal to use them together. See the PHP FAQ
Another relase from the RDMS that told us transactions weren't important and would just slow things down.
Martin Brooks / Slayer99 #linux / UIN 2178117
Hi all,
I keep hearing about all the great god-like features of Postgres....but what exactly can Postgres do that mysql can't? i'm going towards setting up a central database (MySQL) linux server at work which will be accessible via Ms. Access using an ODBC driver from the clients. (ie. client running Msft Access changes data on a mysql database on a linux server, easy enough to use gui and a strong enough backend)
So far, i'm not doing anything out of the ordinary. nothing too complicated database wise. What exactly would be the advantage of using Postgres.
What does it do that mysql can't?
Interesting you should say that.
We have a postgreSQL system (well, cluster) that handles 400-800 queries/second sustained for several hours a day (it's a stock-market information system).
We tried MySQL and decided against it because:
a) It was much, much slower with a large number of concurrent queries.
b) It has really, really bad error reporting - it just silently truncates, converts and discards data.
c) Their implementations of foreign indices is somewhat flawed, and there are no stored procedure or triggers.
(b) was the killer - it's really painful to have to do all your data integrity checking yourself rather than letting the DB do it.
Any discussion of MySQL should include MySQL gotchas:
Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.
Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.
# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust
What are you smoking? Do you even know what goatse is?
Will code a sig generator for food
> But WHY???? There are free alternatives out there that don't have key missing features, and don't force you to write these work arounds.
nostalgia? I mean, there are some folks who really miss that 70s pre-RDBMS coding in IMS, ISAM, etc....
One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas for starters.
The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.
On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.
So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.
In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.
MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.
I get so tired of reading all these "MySQL sucks" comments from the PostgreSQL crowd every time there is any mention of the two databases. Well, for whatever reason, this time I feel compelled to comment in return.
First of all, I remember back when I was trying to decide which of the two databases to use for my bicycle touring community website, crazyguyonabike.com, and I heard all the same arguments that MySQL is a "toy" that's simply an SQL interface to a flat file system, and how PostgreSQL was a "real" database with actual transactions, subqueries and so on... but then, digging further into PostgreSQL, I found out about the 8k row size limit, and the requirement to halt everything to do a VACUUM occasionally. That really set me back on my heels - 8k? That's really pathetic. Ok, so they've fixed that in the later versions, and the VACUUM also seems to be bit less blocking now, but still - it left me wondering just what else these zealots were conveniently choosing to forget about when recommending PostgreSQL. How about speed? How about all the anecdotal accounts of corrupted databases (again, probably improved somewhat more recently). What other major limitations are they conveniently neglecting to mention these days? I ask, because these people were making exactly the same noises back in the 8k rowsize limit, blocking VACUUM days as they are now.
Thing is, MySQL works really well right out of the gate for most things that people want to do in real life. Here are a few factoids for you:
MySQL *does* have real transactions. It has for quite some time now - just use the InnoDB table type. And for anyone who whines about this not being the default table - get a life! Choice is good, and I would say that for 99% of applications out there, you just don't need transactions. Go ahead and crucify me for saying this - I don't care. It works for a lot of people, many companies all over the world use it for heavy duty database work. I've used it for four years now, and it has *never* crashed on me, *never* lost any data. I use RAID and backup regularly too, but MySQL is ROCK SOLID.
MySQL is getting all these things like subselects and procedures, just with a different priority to PostgreSQL. So what? Again, I have never missed subqueries, and I have some pretty complex queries in my website. Again, go ahead and flame me, I don't care - it works for me, and it works for a LOT of other people too. Which brings me to another thing:
There is a definite sense of intellectual snobbery and elitism in many of the comments from PostgreSQL fans slamming MySQL. This reminds me of some of the people I used to know back at University - these are people who are so wrapped up in their own little cozy theoretical worlds that anything remotely practical or pragmatic in its approach seems to be extremely threatening. I think this is one of the big reasons for the bile - these people are simply threatened by the fact that MySQL is so popular and so much more used across the world. Could there also be a little tribalism creeping in here? You know, my team vs your team. They just can't seem to understand that BOTH databases work very well and BOTH databases have weaknesses, which BOTH development teams are working very hard to fix and make better. Getting religious about this sort of thing helps nobody. But, I guess, given the fact that Religion is in fact so widespread in the world, this would then also point to there being a somewhat large number of people who are so hung up on their own little certainties and fixed viewpoints that anything else just can't be left to stand. Like the Christian missionaries, they have to have everyone else adhering to THEIR point of view, regardless of the fact that there are, in fact, many "ways" to spiritual enlightenment (or data management). Again: Not everyone needs transactions. Many people just need simplicity and speed, and they get it with MySQL. And you know what, if they want transactions then they can have that too! Th
Who'd have thought, even this lousy bait attracted some nice Insightful catch... Moderators these days...
...Phew! After today's turkey I don't think I could eat anything else.
--
Why in the hell was that post marked insightful? Older versions of MySQL have all of those things. Why in the hell was a bold-face lie like that moderated upward? This site just gets worse and worse. There are too many idiots with moderator points that moderate good posts downward and trolls upward. I've seen two trolls this week alone that had +5's. Why?
I don't care what anyone else says! It's MySQL 5.0 and we're running away together! You never understand me! Maybe no one else will ever understand us either, but alpha or not, we're n love!
-- 'The' Lord and Master Bitman On High, Master Of All
Does it work as well as Tsearch2?
Tsearch rocked, and Tsearch2 looks to be another giant step beyond.
Is this version ACID-complaint already? How does it compare with PostgresSQL performance-, consistency- and security-wise? Thanks. I am going to start a new database soon and maybe I'll change my mind in favour of MySQL if this new version satisfies the ACID principles.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Check out Drupal. Although primarily developed for MySQL, it does work with PostgreSQL.
You could have just done this.
which is a fucking shitty solution. i worked on a clients server a few months ago and had to comppile in mck support. it was a p2/733 single processor web server. it took nearly over 4 hours to get php recomiled, adding mck support properly. the compile itself took 2 hours and dumped out on a stupid error the first time. now every time redhat pushes a new update for php, we have to block that, myssql and apache and wwait until we can get a new php compiled. what a bunch of shit. someone needs to figure this out because bullshit like this is what will make open source & free software not worth the price of admission. these licensing incompatabilities and all the fucked up games that go with them are a drag on the community.
sometimes i dream that i am on the banks of a river at night, looking at a crowd of small boats all going downstream. each little boat has a little person on it and they are holding a stalk with a glowing light. they see me on the banks with a broken stalk at my feet. ignoring me they press on. i don't feel sad at all. i take for granted my solitude at the banks of the river. /bpr
the thought of one day seeing another like me, with their broken light taps an emotional reserve i didn't think i had
Please mod parent down as a troll -- this is a dupe of a post in the last MySQL story thread (even including the "Don't read this..." section). (And it's redundant to boot, given that we've already had several links to sql-info.de's MySQL Gotchas in this discussion.)
The technique is straight out of the AntiSlash Karma Whoring How-To -- don't let this jerk get away with it.
Il n'y a pas de Planet B.
Yes, and 99% of those reading the comments would not realize how long is the list. The graphic effect of seeing all the areas of quirkiness is informative.
It is easy for me to agree with you that you are mindless, Zontar. So what if it is the same post? It is extremely important in any discussion of MySQL to realize how quirky it is.
Quirkiness is a major problem with MySQL. Once you get started with non-standard implementation, you travel down a path from which it is difficult to return.
I want my sub queries damnit!!!
because what hunting rifle has a bayonet lug
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.
--- It is not the things we do which we regret the most, but the things which we don't do.
if you were using Postgresql.
Congrats on being curious enough to look.
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are:
Point in Time Recovery
Sub transactions
Very low I/O contention vacuuming.
Win32 native port
Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial strength synchronous replication (.org uses postgresql with this solution), GiST indexes, ssl/ssh connections, many new procedural languages (R, PHP, python, java), and most importantly, performance improvements.
--- It is not the things we do which we regret the most, but the things which we don't do.
Yo, asshole. Vacuum is no longer blocking, and the new autovacuum daemon means I can just "set and forget" the database. Maybe you should stop talking about the problems Postgresql had 3 or so years ago, eh?
FYI, I ran a test the other night, with 50 simultaneous transactions running 250,000 bank transactions one at a time each. That's 10,000,000 transactions. It ran in ~ 12.5 hours, at a rate of 220 transactions a second. Even our Oracle servers have a hard time with that kind of sustained load. MySQL would crash and burn long before morning came along.
Maybe you should actually TEST the newest flavor of Postgresql before making yourself look like the clueless idiot you obviously are. Oh, that would actually take effort and time, and you don't have any of that left over after all the time you spend blowing sunshine up your own ass.
Doubtful when you show us no numbers.
To anyone who complains about speed:
(1) Does RDBMS performance actually affect your application, or does the bottleneck lie elsewhere?
(2) Do you really have the numbers for your application behavior, or are you just guessing?
(3) Did you put some minimal informed effort into making the RDBMS perform well, or at least as much effort as you put into the alternative? A good place to start for a postgresql performance problem (hint, hint) would be a detailed description of the problem on pgsql-general.
Social scientists are inspired by theories; scientists are humbled by facts.
>You can do a lot of stuff in MySQL by working around missing features. But WHY????
.. annoying to say the least. How about out of the box replication? (I haven't had a good look at the replication options for postgres to be honest).
Because MySQL permissions are easier to deal with? Doing stuff like changing the owner of a database in postgres is
I'm sure there are things that postgres does that mysql doesn't, or things it does better. However the plain fact is a lot of people don't need those things, and MySQL is a lot easier to deal with in some other important regards. This is one big reason why more webhosts offer MySQL than Postgres databases to their customers (or charge more to deal with postgres)
> Simply because it's been posted to other threads does not make it redundant
No, but the fact that those links had been posted to this discussion several times already does. Thus,
-1 Redundant.
> and simply because it bothers you that someone would point out flaws in MySQL does not make it flame bait.
That's not what I said. This is not a case of "You dissed my DB so I hate you forever" crap, okay? Nor am I knocking the MySQL Gotchas, other than that they're formulated in such a way as to make the originator's prejudices readily apparent, and he tries to make it sound like MySQL AB don't tell you about these things, when in fact, you'd know this stuff if you had RTFM. But it's still a good resource if you keep that caveat in mind.
When somebody puts that kind of stuff in a post to make it obvious that they've done it to defeat the lameless filter, and copy/paste it word-for-word from another thread into this one, and offer absolutely nothing new to the conversation in the process... If it looks like a troll, and acts like a troll, it's a troll. Like I said, it's straight out of the Karma Whoring How-To. Therefore,
-1 Troll.
I haven't bothered to check to see whther or not he copied/pasted his own post, but if it originated with someone else, that'd be
-1 Plagiarism
as well.
> It's also not a troll. Everything in that post is TRUE.
Trolling has nothing to do with whether or not something is true. There is such a thing as malicious honesty, and this guy's guilty of it IMNSHO.
> 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...
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
I don't visit pgSQL threads dumping on postgres, and you'd think some people would be mature enough to return the favour, but I guess not.
My only complaints against PG are:
1. Trying to get it running on Windows is a PITA. (One of the reasons I prefer MySQL is that it is brain-dead easy to install on Linux, Windows, Mac OS X, and about a dozen other platforms, and it runs almost identically on all of them. Given that I work on all three of the OSes I named, that's a very important issue to me.)
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
BTW, I've not been afraid to go against the MySQL AB "party line" -- in print -- when I thought it was wrong or misleading. It's not made them particularly happy with me at times, either, but so it goes. Being dogmatic tends not to do one's readers any favours.
Il n'y a pas de Planet B.
"basic support for SQL-99 stored procedures." sounds great ! it is about time this happened !
Chris ,
Php Programmers.
MySQL is a lot easier to deal with in some other important regards
What other regards? This is a serious question, because I don't think the developers always know. They know everyone wants easier-to-use replication (there are some good solutions out there, but nothing is really "out of the box"). I suppose that changing the owner of a database counts, but I don't think I've ever had to do that. I'll try it out and maybe try to get that fixed.
So, for the benefit of the success of PostgreSQL, what is your wishlist for its improvements?
Social scientists are inspired by theories; scientists are humbled by facts.
Platform makes a big difference to performance... we find same query is about six times slower on Solaris 8 than our notionally similar setup on Red Hat 8. (Yes, we used the Postgresql-recommended kernel parameters.)
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
Is there a GUI? We use SQLyog for MySQL and have not been able to find anything comparable for Postgresql.
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
I learned (and still use) mysql because of its documentation. The manual is huge and comprehensive - single sided, the docs for 3.x take up a 3" binder. These docs (and surprisingly, a book on database programming in vbscript, of all things) are what taught me SQL.
I wanted to switch to postgresql, but at the time (about a year and a half ago) the docs just weren't there for it. I like a nice manual, a la freebsd or mysql. If this has changed, I'd switch to postgresql in a minute.
'Course, for what I (and many others) do, mysql is perfectly suitable. I write web-based databases in PHP (mostly) for small businesses to track customers and products and such. The features postgresql has over mysql are overkill for this sort of work (AFAICT, as I'm not a database guru).
Those who can't do, teach. Those who can't teach either, do tech support.
What does it mean 'ISO SQL:1999-style stored procedures'? Java, PL/SQL, SQL/PSM?
Stored procedures are a mess, with a de facto ill-defined Java standard trend, a de jure SQL/PSM standard supported by IBM DB2 and not much else, and a proprietary, non-portable PL/SQL supported by Oracle and PostgreSQL.
But anyway I won't consider MySQL when I have PostgreSQL with a much sounder, even if not perfect, approach to fundamentals.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
... the goddamn GPL from the client libraries?
Or are they still doing tricks?
> But anyway I won't consider MySQL when I have PostgreSQL with a much sounder, even if not perfect, approach to fundamentals.
> DBA, SysAdmin looking for a job!
Gosh, I know MySQL and I've got plenty of work using it. Glad to see your skills with the "sounder approach" are so marketable.
[backing up your replication server? That's a pathetic solution]
In a way, it's pathetic that this is the only way to do it; in another direction, though, it's a very smart thing to move any activity that doesn't need to happen on the primary (bottleneck) server to a secondary server instead.
A similar practice is commonplace in the MS SQL Server world, running lengthly reporting queries on a secondary reporting database instead of on the primary.
Cool, I get your point on most of what you say, but, this:
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
doesn't fix all the problems. It fixes quite a few, but the ones that are left are still pretty nasty, imnsho.
Further, about Postgresql, you said:
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
I call shenanigans. While the Postgresql docs are not aimed at the beginner, as someone who already understands database theory, I found them quite good. I didn't need someone to point out what a foreign key was or what it could do, only how Postgresql implemented it. While the MySQL docs are great for beginners, they are actually pretty damned cumbersome for people with experience. Also, the Postgresql docs have had a lot of input in the last year or so, so you might want to look at them again.
--- It is not the things we do which we regret the most, but the things which we don't do.
Despite what ivory tower CS folks would like us to believe, it's not practical to apply proofs to all programming to guarentee correct operation. Godel might even argue that it's impossible for any non-trivial algorithem to be bug free. Any program more complex than Freecell can only approach "stable release quality" asymtotically. To achieve what you request, versions would have to be assigned as 4.9, 4.99, 4.999, 4.9999, ... because there's always one more bug.
The alternative would be to re-number versions as they reveal their stability: "Ok, that last 5.0? That was actually 4.9.100, this one is the real 5.0." This would undermine the real purpose of the version number, which is to uniquely identify the VERSION of something.
The version number cannot and should not be used to ascertain the quality of that version. There's no substitute for actually researching or testing the performance of the product to see if it's what you want.
I think the best one around is PgAdmin III at http://www.pgadmin.org
I don't use it much, but it looks very nice and is easy to work with for the little stuff that I have done. It's also cross platform, and I've used it on windows and linux.
Social scientists are inspired by theories; scientists are humbled by facts.
...all my mission critical servers that run MySQL, let the testing commence baybee! ;o)
I am NaN
Even better, pgsql-performance
- Sw Usr
Go with BerklyDB if you are interested in ACID. The two most popular things to come out of Berkly were ACID and UNIX. Coincidence? I think not.
Actually, Windows, is one of the reasons *I* use mysql over postgre... ever tried running postgre on windows? last time I tried, it required a hammer and chissel to make it work.
Now, as for PHP on windows, it's not much harder than running the installer (although win2003 server makes it a little harder)... as for PHP+MySQL, the precompiled binaries have the support built in, even without the extension.dll, so get your facts straight. MySQL is equally easy to install, and the 4.0 runs pretty rock solid.. and does what I need, which is push a *LOT* of data fast...
I am writing ASP.Net applications that run under Windows Server 2003 Web Edition, and connect to a db server running Suse 9.0 + MySQL 4.0.x and it runs like a bat outta hell.
before I get blasted for having windows as my choice of OS for web stuff, is simply ASP.Net rocks... and Mono's (mod_mono) simply isn't stable, and proven enough yet... so, I compomised, I use MS for the webserver, which is a pretty nice price point on the web edition, and connect to MySQL, which means I can test on windows, and deploy to live... pretty much best of both worlds.. beyond that 99.99% of anything I have done to this point runs under mono, which has a more mature MySql Driver (ByteFx) available than the Postgre driver at this time, another reason for mysql.
now, if postgre now has an installer, and runs pretty straight forward under windows (haven't had any issues with mysql under windows), let me know...
Michael J. Ryan - tracker1.info
Note that there has been a lot of work in the last year to get Postgresql running faster on Solaris, including several fixes to Solaris itself, such as it's (Solaris') very very (very very???) slow qsort with lots of equal keys being replaced by BSD's qsort.
You might want to try it again, and report back to the pgsql-performance list to see if they can get you some help.
--- It is not the things we do which we regret the most, but the things which we don't do.