Slashdot Mirror
MySQL 3.23 Declared Stable
redcoat writes "After two long years, MySQL 3.23 has been declared stable. Improvements over 3.22 and .21 include rudimentary transaction support using the BerkeleyDB lib, full-on replication (master/slave configuration) and lots of other goodies. It's been a long wait, but a worthwhile one, no doubt."
Well, compared to what? It doesn't even have a can-opener!
Do yourself a favor and get yourselves a Victorinox Swiss Army Knife with builtin digital altimeter and thermometer, so you can play with a real knife!
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
I'm of the opinion that the open source databases are all so substantially behind the capabilities of the proprietary market leader Oracle that I don't consider them viable replacements for enterprise grade data solutions. I work on a system that has 800 concurrent users at any given moment, and I don't see anything remotely close to worthy of consideration in the open source arena.
Worse, I see Oracle as pulling away. In the last two years, the open source databases have struggled to add features that I view as expected and required while Oracle has added 10X more. Transactions & row-level locking, nested selects, foreign keys, etc... are not optional features. In order to compete, open source needs database projects with forces comparable to the linux kernel, apache, gnome, and KDE projects. I just don't think Larry Ellison is out there worrying about GPL'd competition.
I don't think Oracle gets the proper attention in the open source community. Oracle has a greater "lock in" effect and has mostly got a free ride from the open source community so far. Oracle is a big gorilla that is rapidly becoming the most secure proprietary software vendor around.
Say you have an e-commerce app... one table with orders, one with customer account.
Now say you allow orders to be passed with or WITHOUT an account (don't want to force people on creating an account first).
you have in your orders table a "customer_account" field, can be NULL or can a foreign key to the customer table.
Now you can do this in MySQL :
SELECT * FROM orders LEFT JOIN customers ON orders.custumer_account=customers.account_name WHERE (blablabla)
And then you have in your results either only orders info (if custumer_account is NULL) or orders AND customers info at the same time. No need for two separated requests...
So LEFT JOINS are quite usefull in any table that has a foreign key that can be NULL.
I was really hoping that proper foreign key support would be added by know but was dissappointed to see it missing from the list. I decided to see if it was in the TODO list and was surprised to see full foreign key support in the Things that have to be done sometime section instead of the Things that should be in 4.0 or the Things that must done in the real near future sections. So it looks like full foreign key support won't be around till 5.0 or later. *sigh*
Lack of full foreign key support (and maybe transactions) is the only reason I don't consider mySQL a proper relational database management system as it claims sinceit doesn't enforce relationships via referential integrity checks. In many large complex applications, having referential checks built into the DB is very useful and it would be a great boon if mySQL had this functionality.
Grabel's Law
I'm just disappointed they didn't bump up the version number further to let people know how substantial the release really is.
--JRZ
Does Postgres even support LEFT JOIN yet?
... END when SELECTing from tables with 30,000+ rows is very fast (another thing Oracle don't support at all)
The LEFT JOIN is something I wish they (Postgres) would put in, but then, Oracle don't support it either...
The reasons I prefer Postgres are, to name a few:
Transactions
Sub SELECT's
Using CASE WHEN
Postgres used (pre 6.5.3 i think) to have some memory leaks when using transactions, but this seems to have been fixed in later versions.
This is what I love about the MySQL/PostgreSQL silliness. Postgres is a mostly complete DB, with some things that need work. MySQL is a fast hack with little overhead. For real solutions where you can apply heavy engineering, MySQL's speed advantages can be mitigated away. However, it serves a niche.
If you have a little web site (or even a big one) where integrity is not key and ease of setup is important, MySQL serves that niche. If the improvments don't sacrifice their advantages, go MySQL. However, if they move towards completeness at the expense of speed... well, how silly. We already have Postgres...
Postgres is trying for speed and MySQL for correctness. Yeah... we get two similar systems. I would rather they focus on their advantages so we maintain two useful system.
As a lover of DB theory, I hate MySQL. As a lover of low barriers to entry, I love it. I'd hate to see MySQL lose it's niche by becoming too general.
Alex
If find the big support for MySQL somewhat surprising. When I'm running a RDBMS, I want stability, even if it happen to be a commercial or a open source one.
MySQL have for many years been been considered as a very unstable product and that it have been (still are probably) lacking a lot of really useful features.
In the open source world, I find two RDBMS especially good. PostgreSQL and Interbase. They are both fine products and probably near commercial grade RDBMS standard.
So even if MySQL is now considered stable. So what? We have other choices, which have been developed with great care for many years and have been added features from their stability, not the opposite.
So in my humble opinion, if you want to run anything (semi)serious, definately do not run MySQL, there are MUCH better options out there.