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 found an interesting article
by a fellow who has worked on some
major open source oriented sites.
He does a quick comparison of
postgres and mysql here.
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.
"On weekends, to let off steam, I participate in full-contact origami."
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.
:)
Now, would that be Interbase with or without a compiled in superuser backdoor account?
Of course, for pure SELECT power, nothing beats MySQL. So if you're not inserting data too often, and you don't mind running ISAMCHK every now and then, and data integrity isn't entirely critical (which does work for a surprising number of people), then yay MySQL!
I use it.
Find enclosed some of the conclusions:
- PG does treat BLOBs as part of a tuple, MySQL does.
- There are serious problems with PHP and PG transactions for reading and writing BLOBs in the database. PG forces to use transactions, MySQL doesn't.
- PG doesn't use any index to speed up sorts (ORDER BY clauses), MySQL does. This is a problem for web pages were most of the result are ordered according to articles IDs or modification dates.
- PG, as in V7, doesn't accept tuples of more the 8KB, 32 KB support can be selected at compilation time but speed is seriously affected. There is not this kind of restrictions in MySQL.
- PG does not accept "full-text" indexing and queries.
- In MySQL you can choose if a file to be imported is being read by the backend or the frontend.
- You have to run VACCUM ANALYZE in PG from time to time in order to get your queries optimised.
- PG doesn't allow to do BLOB content search, MySQL does.
- PG accept RULES for executing SQL sentences on table insert or updates, MySQL doesn't.
- NASA has migrated one of their webs to MySQL
;-)
We found that the previous reasons justify the migration to MySQL.--ricardo
sgis ddo ekil t'nod i
Comment removed based on user account deletion
Well done guys and girls.
:) The equivilent freeware solution came to exactly zero dollars (duh). (hardware costs not included, btw).
I'm of the opinion that along with several other open source applications, MySQL is what's helping Linux make large inroads to the enterprise market.
A while back I priced a WinNT solution for a basic e-commerce site, with MS-SQL 7, ASP, and all the rest of the NT fluff needed. It came to over $5,000 Australian dollars (about $7.33 USD
MySQL was a large part of the equation. I was and still am very impressed with it.
Again, well done to the team.
Alas gallinaceas de urbe bovis volo
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
That's also the case when you have two tables, say customers and widgets, and customers can have any number of widgets, including zero. Say you want to display a list of all customers and the number of widgets they have. Implementing it with a simple join, customers with no widgets simply won't show up in the result set. With MySQL there's a way to do it right with left joins. With PostgreSQL so far I've had to use two queries. If there's a way around that someone please tell me. :-)
That's the biggest disadvantage of PG I've found, and it's not *that* big a deal.
I'm just disappointed they didn't bump up the version number further to let people know how substantial the release really is.
--JRZ
Someone fill me in. I don't get the joke.
Or is it just a really bad typo?
No, no...it's just a minor problem with MySQL data integrity. It seems to happen a lot here on Salshdot...
information wants to be expensive...nothing is so valuable as the right information at the right time.
Obliteracy: Words with explosions
The people who are reporting MySQL crashes should submit bug reports. The MySQL people claim they haven't lost data in years, and if that's not true, it needs to be publicized.
The replication feature has been changed a little since the tutorial was written, so you may want to check out the documentation at the MySQL site. Here's a copy of my own /etc/my.cnf file from both machines, which are setup for 2-way replication, for reference (perhaps I'll get around to posting a tutorial of my own later today on The Linux Pimp
Main server /etc/my.cnf file
[mysqld]
log-bin
master-host=ip_address_of_backup
master-user=replicate
master-password=your_password
server-id=1
Backup server /etc/my.cnf file
[mysqld]
log-bin
master-host=ip_address_of_main_server
master-user=replicate
master-password=your_password
server-id=2
--It's Pimptastic!--
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.