Slashdot Mirror
MySQL to Adopt Solid Storage Engine
hmart writes "As seen on ZDNet's Open Source Blog MySQL is taking another step to defend from Oracle's recent acquisitions of InnoBase and Sleepycat. From the article: 'MySQL responds by getting Solid Information Technology, a proprietary database vendor, to take its solidDB Storage Engine for MySQL open source, under the GPL, starting in June.'"
buy out Solid Information Technology.
-Larry Ellison
No matter which storage engine you use in MySQL, the SQL syntax is still the same. All you have to change is the ENGINE= line in your schema definitions.
MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV
"Choices" is positive spin. Some might say that MySQL is all about sacrifices. Here are some examples:
(1) "MySQL has many applications written for it"
* Not if you enable strict mode, or if you use storage engines that don't support the features you need.
(2) "MySQL is optionally SQL compliant with strict mode"
* Only if you want to forego 99% of the existing MySQL applications, and start fresh.
(3) "MySQL has transactions"
* Not in MyISAM, which means no full text indexing.
(4) "MySQL is free"
* Only if your application which links against the client library is also GPL.
(5) "MySQL is fast"
* Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.
I could go on. Anyone can talk about how MySQL has a feature, but you have to make sacrifices for those features. And I think many of those are bad, unnecessary sacrifices. MySQL implements features not to give their users choice, but to give MySQL AB a marketing advantage. Their advocates and salespeople will always say "yes" to all of those features above, but it's not until later that the customer realizes that they can't use the features together.
Social scientists are inspired by theories; scientists are humbled by facts.
Oh, I doubt that there is a single MySQL developer who would be offended. We are not so aloof that we cannot take criticism - actually we welcome constructive criticism, it lets us know what needs to be improved.
Perhaps we have been a bit lazy: Assuming that the partnership with Innobase would continue forever and that MySQL would eventually acquire Innobase.
MySQL has a few advantages - it is a small company which can react quickly to unexpected changes. We learn. Jim Starkey has joined us - he is a veteran of relational database designs and a delight to work with - and we do plan to have our own storage engines with transactional goodness, we already have Cluster but we need something more lightweight usuable by everyone.
In the meanwhile, it is good to take advantage of the MySQL architecture and make partnerships which can make use of one of our strengths. Having 3rd party storage engines is something which has been quietly encouraged for many years and is now something I think will see more publicity.
(disclaimer: opinions are my own and not of my employer nor anyone else)
No sig. Move along - nothing to see here.
The problem being once these important OSS coders see oracle source, they are tainted. Any further OSS contributions will have to be heavily scrutinized for IP violations.
So oracle does not need to keep them. They just need to expose them to even bits of their db source, and they have tainted the coder.
Devious, if you ask me. I am impressed. Or I would be if it didn't damage my own interests.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
Ditto above. Perhaps the existing MySQL user wants to go to strict mode in order to support databases *other* than MySQL. Have you concidered that?
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Myth used to scare people away from opensource GPL code.
Some people would disagree with that statement. Quite a lot of people have found that for their needs, MySQL is lighter and faster (or at least, as fast as the big name products) even when never using MyISAM tables.
There will be people whose needs are best served with products from Oracle, IBM, Microsoft, Sybase... I am sure that no one in MySQL claims that it is the only solution to all problems: MySQL is a young database product which is actively being developed so it will improve.
No sig. Move along - nothing to see here.
I think it would be fun to make MySQL as versatile as possible with a huge choice of plug-ins available. Sort of like what Linux is for operating systems but for databases instead. MySQL is platform agnostic and want it to perform well everywhere, including Microsoft Windows and even... SCO (hey, its not their customer's fault).
If there is anyone out there which has some kind of data storage/retreval system, I am sure that MySQL would be happy to assist and encourage them to make it into a storage engine for MySQL. If they want to GPL their code and join the open-source party, I am sure MySQL would be happy to help in that too.
No sig. Move along - nothing to see here.
This is typical LAMP programmer thinking. What do I need transactions and data integrity in a database for? I'll just code the checks into my application. I prefer instead to put checks both in the database and in the application.
This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.
I'll stick with PostgreSQL. Unlike MySQL, PostgreSQL is a serious alternative to Oracle or MS SQL. It is also BSD licensed and thus there are zero restrictions on its usage within a commercial product and there is no need to purchase a commercial license.
MySQL is okay for the LAMP mentality but when you start getting in to ORM/ERM (Object/Entity relational mapping) with packages like Rails's Active Record or WebObjects's Enterprise Objects you need a more serious database. As another poster has pointed out in this thread I give it only a few more years before mainstream open source web development moves into the ORM camp.
The problem being once these important OSS coders see oracle source, they are tainted. Any further OSS contributions will have to be heavily scrutinized for IP violations.
Yes and no.
Strictly speaking, there is no such thing as a "tainted" developer. There are three different forms of IP law that Oracle might try to use to control what the programmers do after they leave the company:
So, if the developer has access to a good lawyer, it seems like Oracle really can't do much to prevent future work. But, of course, a wealthy corporation can afford legal battles much better than an indiviudal can, and any or all of the above would lend enough credibility to a lawsuit by Oracle that the coder might end up having to fight it in court... which can be really expensive even if you win. Then again, this is exactly the sort of case where the EFF and others would probably be willing to step in and help out.
Finally, if Oracle failed to terrorize the devs into meekly going along, Oracle probably wouldn't want to go to court very much. Not only is it bad PR, but it does cost a lot of money, even if you're a corporation with deep pockets. There has to be a reasonable expectation that the cost is worth the result, which seems pretty unlikely. Threatening a lawsuit you probably can't win doesn't cost much, but actually pursuing one does.
So oracle does not need to keep them. They just need to expose them to even bits of their db source, and they have tainted the coder.
No, I really don't think that's enough. What they really need to do is to terrify the coder with weighty, frightening non-disclosure agreements and non-compete agreements. If they do too much of that, though, they won't get the hire in the first place.
Of course, IANAL. But I have read the relevant law, and have some familiarity with the applicable precedents, thanks to other cases.
I really hope that the open source developers who've gone to work for Oracle have run their employments contracts past attorneys of their own.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"People who choose database vendors and make other such big IT decisions for companies like GM, Boeing, Wal-Mart and such, think "Open source = toy for the geeks"."
Yes that's why no large corporation in the world uses mysql. Hey wait a minute that's a complete lie isn't it? There are lots of fortune 500 corporations using mysql aren't there. Never mind.
"They want top notch support, perhaps even an Oracle team to be on-site for a couple of months during deployment, they want someone to blame and to complain to when things don't work right. MySQL provides support but it is just not going to be the same quality."
Spoken like somebody who has never bought support from oracle or mysql. If you pay mysql half of what you pay oracle for support they will give you the phone number of a developer. How is that for support?
Mysql offers some of the best support of any database vendor. Go ask any of their big costomers. Then compare what they say to the customers of oracle.
I don't mean to be a cheerleader for mysql but I really really get tired of the same old "you can't get support or blame somebody" FUD about open source.
It's over, strike that item from your big book of FUD and find something else to complain about mkay?
evil is as evil does