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."
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
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
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
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...)
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
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.
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.
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
This rant brought to you by a Squadron of Attack Kittens.
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!!
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)
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?
Re:Not that uncommon
by
AntiOrganic
·
· Score: 2, Funny
If it's good enough for kernel.org it's good enough for me.
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.
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
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...
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.
Re:The big question:
by
Anonymous Coward
·
· Score: 2, Funny
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.
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.
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.
Just an observation from a database newbie.:)
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.
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
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?
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.
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
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
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
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.
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
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.
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).
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.
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.
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
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
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)
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?
If it's good enough for kernel.org it's good enough for me.
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!
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.
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.
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
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?
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
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
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.
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).
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.