Slashdot Mirror
MySQL 5 Production in November
thatoneguyfromphoeni writes "CIO.com is reporting that MySQL AB is eyeing Nov. for the production release of MySQL 5. 'The company is calling version 5 its most significant upgrade yet. It adds a handful of features considered important for enterprises that have long been available from market leaders Oracle Corp., IBM Corp. and Microsoft Corp. Chief among them are triggers, views and stored procedures.'"
Sneaking in just in time before MS SQL 2005 can get out the door (or perhaps just after) is good for this.
I recently showed the latest rev to the SQL devs here, and they were most impressed. Most of the complaints about it were gone; the new GUI is miles beyond what they had before, and the new features (views, stored procedures, better VARCHAR support) have people thinking that for smaller projects, MySQL will work out just as well as MS-SQL, and at a fraction of the cost, if any cost at all.
You can never go home again... but I guess you can shop there.
You have attempted to launch a SQL injection attack on slashdot.
You have failed.
Please try again with the correct schema.
What sort of hardware is behind RubyForge?
240000 hits/day is just under 3 hits/second, after all.
When you consider the power of today's hardware, it should be able to cope with such a load, even when doing fairly heavy database activity.
Cyric Zndovzny at your service.
I mean, I never see a host offering MySQL. all they offer is PostgreSQL!
Please give me an example where mySQL is a better choice for an application as opposed to PostgreSQL. I can only think of two, neither of which point to mySQL being a superior product.
Sure I'm paranoid, but am I paranoid enough?
Yes, mostly mainframes, but I've no doubt that some industries were running
"enterprise" apps 5 years ago on platforms that aren't as robust as MySQL5 is now. Yes, software has become more demanding in the past few years, but the fundamentals haven't changed. If you could run 'enterprise' solutions on SQL Server 6.5 (and I saw companies doing it - and gosh, they didn't even have row level locking!) surely some "enterprise" industries can use MySQL5 today.
creation science book
I'm hoping, because they didn't need to.
From what I understand there are several developers at MySQL who understand the innodb codebase extremely well. The first smell of trouble from Oracle and they fork the last GPL version and take it from there.
I personally believe that Oracle bought Innobase to get their hands on the developers hoping to starve development on innodb. I hope that that isn't the case, or even possible.
Innodb, imho, is a seriously nice transaction engine. It's very very Oracle in it's design. I'm still not entirely sure why they haven't thrown out MyISAM in favour of it. It performs just as well and has no downsides. The old myth of keeping it lean and fast in favour of MyISAM is a bunch of rot. InnoDB is extremely fast.
Can you please elaborate on what mysql does better than PG as a DB server? And what it does better than SQLite as an embedded database?
From my testing, it is not stronger on any counts: Features, performance, scalability, resource use, licensing, support costs.
I am not bashing, I just have never found a good use for mysql myself, I just use it because so much PHP code requires it.
I am sure I will be modded a troll for this, but the mysql devs did say that triggers, views, even transactions were unnecessary!
Almost every database out there impliments an ISO or similar SQL standard as it's base (SQL-92 in most cases). They then build on top of that by adding their own features, while still supporting the common SQL syntax. It's not about being a barebones implimentation of a standard, it's about supporting the standard as your base.
PostgreSQL supports SQL-92, while adding it's own extra features (which describes most other databases like Oracle and MS SQL too), including the support of the "LIMIT" statement. MySQL doesn't support any standard base, instead existing as an arbitrary mish mash of standard and propritary SQL. It wasn't until the current version, 4, that MySQL even bothered to add support for UNION.
With every other database you can start working safe in the knowledge that while having it's own extensions, you're working with a normal "SQL" database. MySQL, while posing as SQL, has little if anything in common (in particular see threads about optimization - getting fast code in MySQL means learning an entirely new system filled with quirks and vomit inducing workarounds to solve language faults)
I'd say they're more often used to implement security than for reporting these days. If you've got a table which you only want certain rows or columns to be visible to particular users, generate a query that yields the right data for them and turn it into a view. Then grant them permissions to the view but not to the underlying tables.
Try reading this to understand just how broken MySQL (and others) is.
Beware, Nugget is watching... See?
MySQL still requires you to choose a particular (non-default!!) table type in order to have ACID
And with Oracle's purchase of InnoBase, maker of InnoDB, there is a reasonable chance that MySQL will end up dropping the InnoDB storage engine. After all, since InnoDB is GPL, MySQL AB only has a right to distribute InnoDB under a commercial license because of a contract with InnoBase. Here are the possible outcomes:
(1) Oracle renews the contract, and nobody worries until next time it comes up for renewal.
Unlikely. Why do you think Oracle bought InnoBase? Not to be nice, that's for sure.
(2) Oracle doesn't renew the contract, MySQL continues development, and drops it from their commercial version.
Approximately 0% chance of happening. What's in it for MySQL aside from the bad PR of having a commercial version worse than the GPL version?
(3) Oracle doesn't renew the contract, MySQL drops support for InnoDB, and the MySQL community forks, and MySQL develops another storage engine.
Could happen. I have my doubts that would go very smoothly in the timeframe allowed. Most likely some functionality would change, breaking compatibility with existing InnoDB applications.
(4) Oracle doesn't renew the contract, MySQL drops support for InnoDB, and the MySQL community forks, and MySQL doesn't develop another storage engine.
Seems likely, although they lose ACID and foreign keys, which are the most important "Enterprise" features of all.
So, it seems pretty much like #3 or #4, neither of which is good for the MySQL users. Expect MySQL AB to start preparing by warming up to BerkeleyDB to see if they can make that storage layer work. Expect MySQL AB to start spreading propoganda about how foreign keys and ACID really aren't necessary and only slow the database down (they can just un-rewrite some history and the propoganda is already there!). And expect them to try to make something out of SAP DB / MAX DB in a hurry. They'll try to get MySQL 5 out ASAP so that the impending problems with InnoDB don't take steam away from their release.
Social scientists are inspired by theories; scientists are humbled by facts.
Views are a nice feature, but most often used to support business and reporting. I don't like managers connecting to the database to run queries.
Yeah, what kind of crazy person would use a database engine to support managers in making business decisions. Wild, I tell you, just far out!
The truth is that since MySQL doesn't allow you to define constraints on how long queries launched by a specific user can run, you've concluded that allowing ad hoc queries is a bad practice. That's tunnel vision, not insight.
Erlang.org: wow
Silently truncating strings inserted into a varchar(x) field.
Allowing dates like Feb 31st.
Truncating numbers silently.
Strange NULL handling.
A lot more.
Social scientists are inspired by theories; scientists are humbled by facts.
What worries me is that new acquisition of InnoBase by Oracle a few days ago.
InnoBase is the maker of InnoDB, which is the full featured dual licensed storage engine with transactions, referential integrity, hot backups and more.
The GPL version of MySQL will not be affected should Oracle decide to misbehave.
What may get affected is the commerical version of MySQL. Oracle can demand a hefty price for relicensing InnoDB, when the contract is up for renewal hence choking MySQL AB financially, by depriving it from the revenue stream of commerical licensing MySQL with InnoDB.
This may in turn cause long term trouble for the community by depriving it from contributions by MySQL.
I hope Oracle does not do that, but still, they are a corporation with no open source culture, and may have the mentality of choking the competition, using the very rules of open source dual licensing.
Or, they may be softening MySQL to buy them cheap in the near future ....?
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.