Unfortunately for MySQL AB, that would only allow them to release the resulting combination under the GPL. They would not be able to sell proprietary-licensed versions for $400 or so a crack.
That kind of undermines the whole "You're always safer if you buy commercial licenses" thing...
In any world where networks provide thousands of times less bandwidth than local access to memory, the conclusion will remain the same.
The stored procedure can take advantage of the fact that it can commonly find cached data in memory, which means that it's getting on the order of Gigahertz of bandwidth, as compared to 10Base100, which will provide (divided by 8:-)) the equivalent of 12.5MHz, therefore providing superiority of about a factor of 80. That's nearly two decimal orders of magnitude (or, a bit over 6, for those that are binary-inclined).
The next generation of networks will be faster; so also will be the next generation of CPUs. The multiple-order-of-magnitude superiority of stored procedures is likely to persist.
As for physical storage representations, it seems to me that it's better to leave the choices to people who are competent enough to grasp such things as "two orders of magnitude difference." One of the points of "relational databases" is that the user doesn't need to care what is the physical representation if they are properly using the logical model.
"You really, really want to avoid the bottleneck on the database."
Right. So you ideally want to submit one query to the database, that performs all of the changes using one network roundtrip, parsing one query, once.
That is what happens if you submit a stored procedure request.
If, instead, you have the application servers do all that work, the application servers will be firing off a whole flurry of queries back and forth. If there are 6 tables to update, there could easily be a series of a dozen queries to submit and process. That will put a much greater burden on the database server than the stored procedure.
It is regrettably typical for people not to grasp that stored procedures actually reduce the amount of work that needs to be done...
"CSI is so-so on the techical aspects of science, but very, very good on the attitude of scientists, especially in showing them as ordinary people with ordinary problems who also have this common focus on fact and evidence that really does make them different from most other people."
Unfortunately, for those that would use it as example, the people are sufficiently obsessed with the job that there pretty much aren't any of them that "have a life."
I don't think you can become a Ph.D like the Gil Grissom character without a strong degree of obsessive-compulsive disorder; that seems entirely common to Ph.D students... Unfortunately, that is one of the common aspects to these sorts of "details-matter" areas of study that may legitimately scare some people off...
Clearly the religion of Star Trek is the religion of science.
I don't really see how this could be considered to have "held back" the series.
Its religion wasn't exactly "science"; that is about the physics and chemistry and biology of things. It might be better to say there was a "Zen of Star Trek," a perspective on the universe that was uniquely Roddenberrian...
A vital part of it was the notion that the evolution of humanity would become some form of "godhood" in the universe. Anyone that has a problem with "Intelligent design" being considered "scientific" should have the same problem with this...
In any case, I'm not sure the issue is so much that Roddenberry's anti-religious attitudes held anything back as it is that it is pretty clear that the whole quasi-respectful treatment of Bajoran religion wouldn't have take place on his watch.
It is quite reasonable for a military commander who doesn't have any background in an alien religion to be a tad skeptical about them viewing him as a vitally important (to their religion) "Emissary." But in TOS, and, to a lesser degree, TNG, religious institutions weren't simply a matter for "a tad of skepticism;" they were either:
A front for a powerful alien presence cementing their physical power with religious trappings, or
Something made up by superstitious primitives that worshipped some phenomenon whose science they could not or would not understand, or
A front constructed to fortify a political movement,
none of these being honestly deserving of "worship," or, for that matter, much more than pitying derision.
Was the change in DS9 bad? I dunno; I just know it wasn't consistent with the way Roddenberry had worked before...
My only wish was that it spoke FireWire, as if it did that, I could in principle hook up some of those 1TB little FireWire arrays.
It takes a little bit of hackery to get the NSlug useful for Linux; you need to install some alternate binaries so that you can put it in as an NFS mount. It's pretty slick from there...
Yes, indeedy. Evidently you looked at what the patents were on, unlike everyone else that thought that they were patents on filesystems.
Yes, indeed, the patents Microsoft was granted were not on how to make a filesystem, but rather how to munge filenames in a particular fashion. It's what allows you to create long filenames that appear to be in StudlyMiXeDCase.
It may indeed not be the USB key makers that get bit by this; they don't have to do any mapping there...
If MONO turns out to be breaking MSFT patents, then I'd have to wonder why Java wouldn't also be...
Java has had the same trouble as C++; you can use it for things, as long as you chose a particular subset of the language/environment to use. With C++, if you go past [some subset], madness and insanity result; with Java, it's not madness, but rather that you're tied to someone's proprietary Java implementation.
If you had watched more carefully, you'd see that I never said anything about "free.NET"...
There is a merit of MONO over Java, for free-ish software, namely that it is likely to be a more uniform platform than Java.
The trouble with Java, at present, is that full implementations (complete with all the latest J2EE, Java 1.whatever-is-latest) are proprietary to Sun and other commercial vendors. You can't include a full-scale Java with a Linux distribution; the licenses won't permit it, as the implementations aren't "free" the way Linux and attendant software in a Linux distribution need to be.
The lowest common denominator takes you back to partial implementations of Java 1.2 or the like; Kaffe, Classpath, and the like, with no Swing GUI and I'm not sure if Eclipse will run well with these "partial" Java environments.
MONO avoids all that; the free implementation is reasonably full featured, seemingly moreso than the "libre software" implementations of parts of Java.
I doubt it'll actually provide all that much interoperability with Windows. But the point of it was that the Ximian folk were getting tired of fighting with writing C memory management code for dynamic applications like Evolution. If they can write "Evolution Next Generation" using MONO, and have it be smaller, more componentized, more powerful, and more robust than struggling with the C version, that could be the "killer app" that makes MONO worthwhile in its own right, ignoring Microsoft's software.
It seems to me that Beagle is one of the relevant components for MONO-based "killer apps."
It uses a byte-compiled code system called CLR that ought to be platform-independent
It involves a whole lot of add-on libraries for additional services akin to J2EE
The 'official' language, C#, is remarkably similar to Java
It is, in effect, Microsoft's "alternative" to Java.
The troublesome part, for those with wishful thoughts about portability, is that Microsoft can implement and encourage use of components not implemented in C#/CLR, but that instead are linking to "pure Win32" stuff. For instance, it makes sense to try to tie in as deeply and "proprietarily" as possible to their versions of Sybase SQL Server, IBM MQ-Series, web servers, the Win32 GUI, and such. That sort of thing is what will provide the desired anti-Java "vendor lock-in."
The trouble with the film is that it (presumably) is fairly faithful to the earlier cartoon-based stories, which represents a fairly huge body of "complexity of world-view" that is really tough to fully express in the scope of the couple hours you may spend in the theatre.
In effect, if I were creating a movie, from scratch, with no back-story of old material to have to agree with, the story would have been exceedingly different, as there would be no need to express many aspects of the world that the back-story forced them into.
Leaping into this story without the backstory is just like leaping into the story of Serenity; plenty about the situation will be bewildering detail that exists in order to satisfy the longstanding fans.
We have run into pretty big scaling issues on Linux; once you get to the point of wanting fibrechannel + disk array, you hit limits on Linux reliability pretty badly, alas.
One of our staff got really good at destroying Linux filesystems. Every variety was highly vulnerable; she'd pull one of the fibrechannel connections, and watch the systems fall down. Some of the problems were pretty nicely replicable on the Dell 6600 series on various media...
The thing I'd hope to get with Sun hardware + OS is actually two things:
Firstly, I'd expect not to be getting Dell's "cruddy hardware of the week." Check anywhere: You'll find it deprecated. Google for dell postgresql performance and the first link you're likely to see is Hardware for best performance which quotes someone I work with:-).
The Dell stuff has a history of underperforming compared to other hardware with apparently similar specs. It appears that their habit of buying whatever the hardware manufacturers are remaindering this week applies about as much to servers as to desktops, and the results suck.
Secondly, hopefully Solaris plays a bit better than Linux as far as behaviour of filesystems under stress goes.
We discovered with the fibrechannel situation that if you lose a cable or power, Linux has a habit of scribbling on things, thereby destroying data. Oops, if that was an important database, you're in trouble.
I'm no raving BSD-o-Phile; my name is not Dave Gilbert; I use, and like, Linux plenty. Unfortunately, reliability in this area is something that is lacking. AIX played way better; that's what we're using, even though I'd rather put burning needles in my eyes than spend the day coding on AIX. (I don't even want to talk about shared libs on AIX... Ghack...)
That's not a straight answer to all of your issues, but hopefully it gives some ideas:-).
Re:Putting this into language for non DB people
on
Oracle Acquires Innobase
·
· Score: 2, Interesting
This is totally wrong as far as the typical sorts of "use cases" for MySQL(tm) are concerned.
If you're creating a BLOG or web forum, foreign keys and transaction management aren't vital in the way they are for financial applications.
It is so easy (see the MySQL Gotchas site) to accidentally lose transactional and foreign key support even if you installed InnoDB libraries that it is pretty dangerous to depend on the notion that any of the "data integrity" functionality is actually in place.
And the classic sorts of MySQL(tm) applications were written for version 3.23, so it is common to be unable to use InnoDB on the longstanding web apps.
At OSCON, the MySQL AB guys seemed pretty uncomfortable with the notion that the new versions had to support all this data integrity stuff. This buyout can let them head back to what they are comfortable supporting.
This represents no material change to who is able to get changes into InnoDB...
Last week, it was only the staff of InnoDB that could commit changes to a product that, in order to license it under traditional proprietary licenses, required that they have exclusive ownership of all code in the code base.
The Oracle buyout merely changes the name of the corporation holding exclusive ownership of the codebase.
Remember: Unless InnoDB AB granted MySQL AB a pretty non-restricted source code license, then the only thing that MySQL AB would continue to have access to is the GPL-licensed 'branch,' which would mean that they become forbidden to "duel-license" products involving InnoDB.
You can still get licenses for some of these if you really try, but it has been quite clear that Oracle bought them more to take over the market for their own products than to "enhance" the prospects for the products.
This will most certainly turn the continued availability of the "transaction-oriented" InnoDB engine into a delicate dance between MySQL AB and Larry Ellison.
If MySQL AB had "disinterest" in competing with Oracle before, this will most certainly strengthen that disinterest, because Oracle has acquired ownership of the bits of MySQL(tm) that could be pointed in an "Oracle-competing" direction...
It means that if you depend on MySQL + InnoDB, then you are dependent on the continuing "good graces" of two companies, and MySQL AB is dependent on Oracle for ongoing availability of licenses to the "non-GPLed" deployment of InnoDB.
If anything adverse happens to any of the relationships, the Gentle User is pretty screwed.
I could easily see this representing a plan by Oracle to set MySQL AB back.
Note that if Oracle ceased selling InnoDB licenses to MySQL AB, the availability of a "GPLed fork" is completely useless to anyone that was purchasing licenses from them in order to avoid all the (purported and/or real) encumbrances of the GPL. In effect, it would make some forms of MySQL undistributable for any useful purpose.
They are all certainly talking nice right now; that doesn't warrant anything a year from now...
According to this Oracle Press Release on InnoDB Acquisition, Oracle has purchased Heikki Tuuri's company that was responsible for providing the "ACID engine" for MySQL(tm).
That would make it really awkward for MySQL AB to say anything to the effect that they intended to somehow compete with Oracle. It would presumably be grounds for terminating the ability for MySQL AB to continue to sell their product with a transactional engine...
More precisely, thousands of webmasters want something that appears simple.
Something that will stuff in data, whether it's valid or not, because writing code that responds to errors reported back by the database is far too complex for their "simple" needs.
"The whole world's a BLOG" is the typical sort of user space for MySQL(tm), and if that is what the product's owners perceive, I think that means they are plenty perceptive about its limitations.
Seeing as how Sun implements their OSes in C/C++, and also implements Java in C/C++, it makes perfect sense to "bolster" the strategy by having the data store implemented in C, as is the case with PostgreSQL.
The natural thing for them to contribute which would be self-serving would be in the area of JDBC support, where improvements to the interface to data storage represent something they would be especially well placed to provide. It would also make sense to contribute to one or the other of the projects that allow implementing stored procedures in Java...
There is nothing about a DBMS being implemented in Java that ought to make it particularly attractive to Sun, particularly when they would have grave reservations surrounding licensing arrangements.
The recent fragmentary support for PostgreSQL in cPanel is more a joke than anything else. My hosting provider (which uses cPanel) now does provide "vague" PostgreSQL support, which essentially doesn't work.
In any case, recent addition of non-support is irrelevant. cPanel has supported MySQL(tm) for years and years now, including having a barrel of tools that depend on MySQL(tm).
1. MySQL supports all of the Oracle features you need to build and operate an enterprise software system.
Ummm... no. MySQL does not have user-defined data types, object-relational extensions, full support for the CHECK constraint (a big one IMHO), views in a stable release, updatable views, rules, stored procedures in a stable release, synonyms, support for more than one autoincrement column per table, automatic conversion of code pages between client and server, nested transactions, complete trigger support, access privilege grouping, access to multiple databases in one session, multi-master replication, gateways to other DBMSs, XML data and transformation tools, and better tools for recovery from failures.
Actually, as of somewhere between 4.0.x and 5.1, MySQL(tm) does gain "enough" functionality to be able to (in some sense) support the operation of THE "enterprise system," namely SAP R/3.
It was interesting to watch the presentation by the MySQL guys at OSCON last month; I think that at some point they actually did mention that they had introduced all of the functionality actually required by SAP R/3.
Note that SAP R/3 does not require:
Triggers
Foreign keys
Significant "domain" functionality / CHECK CONSTRAINTS (e.g. the lack of verification of date values in the database is not an issue; even on Oracle, R/3 uses plain CHAR fields for dates)
Stored procedures
R/3 does all of those sorts of things (as much as it does them) in the application, that is, in the several gigabytes of ABAP/4 code.
In principle, I don't think there's anything that was needed to support "enterprise software" like R/3 aside from the introduction of the InnoDB transaction manager.
You may want to object and say, "Oh, but I mean for developing NEW enterprise software, not stuff written for IMS back in the 1970s."
To which my response would come in two parts:
Well, the Business Strategy at MySQL AB has clearly chosen the above route. Unless you're planning to pay them $Millions in licensing fees, you're not a market; you're an irrelevant consumer.
And if your desire is not to support legacy application that make less than the most primitive use of the DBMS, then clearly your "use case" doesn't fit with this, and you should probably look at something else.
A year ago, I was puzzling over the MaxDB deal; the only scenario that made any sense about it was for this to represent an opportunity for MySQL AB to, by supporting MaxDB for a while, to figure out the exact minimum set of features that they need to add to their own product in order to attract SAP AB's interest the next time they feel the need to rattle sabers at Oracle over licensing fees.
Considering that this is a route into playing high level games with some of the biggest "totally proprietary" vendors out there, that should cause concern for anyone in the free software community...
You're right; the thing is that the Big Wins come not from those obvious things, but rather from any sort of disk file that is updated really frequently.
Database transaction logs are a good example of this; the cost of a transaction is normally:
The cost of asking for data to head towards disk
The time it takes for the disk to seek to the appropriate location
The time it takes for the data to be written out
The time it takes for the response to come back confirming that the preceding steps have completed.
The benchmarks suggest that the "writing out" part may be about 6 times faster; they tell nothing about what the impact will be of dropping seek time from several milliseconds to, essentially, zero.
Anything that involves a disk round trip with a seek can see an immense improvement. That certainly includes:
Transactional databases
Possibly nontransactional databases
But in general, what is most helped are things you update a lot . It won't be materially better than having more RAM for cache for anything else. It will be stupendously better than RAM cache for things that you want to quickly fsync() to disk.
Slashdot Mirror
Oracle previously bought InnoDB OY, who were the vendor of the other (non-SQL) transactional engine used by MySQL(tm).
That kind of undermines the whole "You're always safer if you buy commercial licenses" thing...
The stored procedure can take advantage of the fact that it can commonly find cached data in memory, which means that it's getting on the order of Gigahertz of bandwidth, as compared to 10Base100, which will provide (divided by 8 :-)) the equivalent of 12.5MHz, therefore providing superiority of about a factor of 80. That's nearly two decimal orders of magnitude (or, a bit over 6, for those that are binary-inclined).
The next generation of networks will be faster; so also will be the next generation of CPUs. The multiple-order-of-magnitude superiority of stored procedures is likely to persist.
As for physical storage representations, it seems to me that it's better to leave the choices to people who are competent enough to grasp such things as "two orders of magnitude difference." One of the points of "relational databases" is that the user doesn't need to care what is the physical representation if they are properly using the logical model.
Right. So you ideally want to submit one query to the database, that performs all of the changes using one network roundtrip, parsing one query, once.
That is what happens if you submit a stored procedure request.
If, instead, you have the application servers do all that work, the application servers will be firing off a whole flurry of queries back and forth. If there are 6 tables to update, there could easily be a series of a dozen queries to submit and process. That will put a much greater burden on the database server than the stored procedure.
It is regrettably typical for people not to grasp that stored procedures actually reduce the amount of work that needs to be done...
Unfortunately, for those that would use it as example, the people are sufficiently obsessed with the job that there pretty much aren't any of them that "have a life."
I don't think you can become a Ph.D like the Gil Grissom character without a strong degree of obsessive-compulsive disorder; that seems entirely common to Ph.D students... Unfortunately, that is one of the common aspects to these sorts of "details-matter" areas of study that may legitimately scare some people off...
What with Takei having "come out," and Gerrold having done so probably 30 years ago, this probably has some, erm, "pretty gay possibilities."
Its religion wasn't exactly "science"; that is about the physics and chemistry and biology of things. It might be better to say there was a "Zen of Star Trek," a perspective on the universe that was uniquely Roddenberrian...
A vital part of it was the notion that the evolution of humanity would become some form of "godhood" in the universe. Anyone that has a problem with "Intelligent design" being considered "scientific" should have the same problem with this...
In any case, I'm not sure the issue is so much that Roddenberry's anti-religious attitudes held anything back as it is that it is pretty clear that the whole quasi-respectful treatment of Bajoran religion wouldn't have take place on his watch.
It is quite reasonable for a military commander who doesn't have any background in an alien religion to be a tad skeptical about them viewing him as a vitally important (to their religion) "Emissary." But in TOS, and, to a lesser degree, TNG, religious institutions weren't simply a matter for "a tad of skepticism;" they were either:
- A front for a powerful alien presence cementing their physical power with religious trappings, or
- Something made up by superstitious primitives that worshipped some phenomenon whose science they could not or would not understand, or
- A front constructed to fortify a political movement,
none of these being honestly deserving of "worship," or, for that matter, much more than pitying derision.Was the change in DS9 bad? I dunno; I just know it wasn't consistent with the way Roddenberry had worked before...
My only wish was that it spoke FireWire, as if it did that, I could in principle hook up some of those 1TB little FireWire arrays.
It takes a little bit of hackery to get the NSlug useful for Linux; you need to install some alternate binaries so that you can put it in as an NFS mount. It's pretty slick from there...
Yes, indeed, the patents Microsoft was granted were not on how to make a filesystem, but rather how to munge filenames in a particular fashion. It's what allows you to create long filenames that appear to be in StudlyMiXeDCase.
It may indeed not be the USB key makers that get bit by this; they don't have to do any mapping there...
Java has had the same trouble as C++; you can use it for things, as long as you chose a particular subset of the language/environment to use. With C++, if you go past [some subset], madness and insanity result; with Java, it's not madness, but rather that you're tied to someone's proprietary Java implementation.
If you had watched more carefully, you'd see that I never said anything about "free .NET"...
The trouble with Java, at present, is that full implementations (complete with all the latest J2EE, Java 1.whatever-is-latest) are proprietary to Sun and other commercial vendors. You can't include a full-scale Java with a Linux distribution; the licenses won't permit it, as the implementations aren't "free" the way Linux and attendant software in a Linux distribution need to be.
The lowest common denominator takes you back to partial implementations of Java 1.2 or the like; Kaffe, Classpath, and the like, with no Swing GUI and I'm not sure if Eclipse will run well with these "partial" Java environments.
MONO avoids all that; the free implementation is reasonably full featured, seemingly moreso than the "libre software" implementations of parts of Java.
I doubt it'll actually provide all that much interoperability with Windows. But the point of it was that the Ximian folk were getting tired of fighting with writing C memory management code for dynamic applications like Evolution. If they can write "Evolution Next Generation" using MONO, and have it be smaller, more componentized, more powerful, and more robust than struggling with the C version, that could be the "killer app" that makes MONO worthwhile in its own right, ignoring Microsoft's software.
It seems to me that Beagle is one of the relevant components for MONO-based "killer apps."
- It uses a byte-compiled code system called CLR that ought to be platform-independent
- It involves a whole lot of add-on libraries for additional services akin to J2EE
- The 'official' language, C#, is remarkably similar to Java
It is, in effect, Microsoft's "alternative" to Java.The troublesome part, for those with wishful thoughts about portability, is that Microsoft can implement and encourage use of components not implemented in C#/CLR, but that instead are linking to "pure Win32" stuff. For instance, it makes sense to try to tie in as deeply and "proprietarily" as possible to their versions of Sybase SQL Server, IBM MQ-Series, web servers, the Win32 GUI, and such. That sort of thing is what will provide the desired anti-Java "vendor lock-in."
In effect, if I were creating a movie, from scratch, with no back-story of old material to have to agree with, the story would have been exceedingly different, as there would be no need to express many aspects of the world that the back-story forced them into.
Leaping into this story without the backstory is just like leaping into the story of Serenity; plenty about the situation will be bewildering detail that exists in order to satisfy the longstanding fans.
One of our staff got really good at destroying Linux filesystems. Every variety was highly vulnerable; she'd pull one of the fibrechannel connections, and watch the systems fall down. Some of the problems were pretty nicely replicable on the Dell 6600 series on various media...
The thing I'd hope to get with Sun hardware + OS is actually two things:
- Firstly, I'd expect not to be getting Dell's "cruddy hardware of the week." Check anywhere: You'll find it deprecated. Google for dell postgresql performance and the first link you're likely to see is Hardware for best performance which quotes someone I work with
:-).
- Secondly, hopefully Solaris plays a bit better than Linux as far as behaviour of filesystems under stress goes.
That's not a straight answer to all of your issues, but hopefully it gives some ideasThe Dell stuff has a history of underperforming compared to other hardware with apparently similar specs. It appears that their habit of buying whatever the hardware manufacturers are remaindering this week applies about as much to servers as to desktops, and the results suck.
We discovered with the fibrechannel situation that if you lose a cable or power, Linux has a habit of scribbling on things, thereby destroying data. Oops, if that was an important database, you're in trouble.
I'm no raving BSD-o-Phile; my name is not Dave Gilbert; I use, and like, Linux plenty. Unfortunately, reliability in this area is something that is lacking. AIX played way better; that's what we're using, even though I'd rather put burning needles in my eyes than spend the day coding on AIX. (I don't even want to talk about shared libs on AIX... Ghack...)
If you're creating a BLOG or web forum, foreign keys and transaction management aren't vital in the way they are for financial applications.
It is so easy (see the MySQL Gotchas site) to accidentally lose transactional and foreign key support even if you installed InnoDB libraries that it is pretty dangerous to depend on the notion that any of the "data integrity" functionality is actually in place.
And the classic sorts of MySQL(tm) applications were written for version 3.23, so it is common to be unable to use InnoDB on the longstanding web apps.
At OSCON, the MySQL AB guys seemed pretty uncomfortable with the notion that the new versions had to support all this data integrity stuff. This buyout can let them head back to what they are comfortable supporting.
Last week, it was only the staff of InnoDB that could commit changes to a product that, in order to license it under traditional proprietary licenses, required that they have exclusive ownership of all code in the code base.
The Oracle buyout merely changes the name of the corporation holding exclusive ownership of the codebase.
Remember: Unless InnoDB AB granted MySQL AB a pretty non-restricted source code license, then the only thing that MySQL AB would continue to have access to is the GPL-licensed 'branch,' which would mean that they become forbidden to "duel-license" products involving InnoDB.
You can still get licenses for some of these if you really try, but it has been quite clear that Oracle bought them more to take over the market for their own products than to "enhance" the prospects for the products.
This will most certainly turn the continued availability of the "transaction-oriented" InnoDB engine into a delicate dance between MySQL AB and Larry Ellison.
If MySQL AB had "disinterest" in competing with Oracle before, this will most certainly strengthen that disinterest, because Oracle has acquired ownership of the bits of MySQL(tm) that could be pointed in an "Oracle-competing" direction...
It means that if you depend on MySQL + InnoDB, then you are dependent on the continuing "good graces" of two companies, and MySQL AB is dependent on Oracle for ongoing availability of licenses to the "non-GPLed" deployment of InnoDB.
If anything adverse happens to any of the relationships, the Gentle User is pretty screwed.
I could easily see this representing a plan by Oracle to set MySQL AB back.
Note that if Oracle ceased selling InnoDB licenses to MySQL AB, the availability of a "GPLed fork" is completely useless to anyone that was purchasing licenses from them in order to avoid all the (purported and/or real) encumbrances of the GPL. In effect, it would make some forms of MySQL undistributable for any useful purpose.
They are all certainly talking nice right now; that doesn't warrant anything a year from now...
That would make it really awkward for MySQL AB to say anything to the effect that they intended to somehow compete with Oracle. It would presumably be grounds for terminating the ability for MySQL AB to continue to sell their product with a transactional engine...
Something that will stuff in data, whether it's valid or not, because writing code that responds to errors reported back by the database is far too complex for their "simple" needs.
"The whole world's a BLOG" is the typical sort of user space for MySQL(tm), and if that is what the product's owners perceive, I think that means they are plenty perceptive about its limitations.
The natural thing for them to contribute which would be self-serving would be in the area of JDBC support, where improvements to the interface to data storage represent something they would be especially well placed to provide. It would also make sense to contribute to one or the other of the projects that allow implementing stored procedures in Java...
There is nothing about a DBMS being implemented in Java that ought to make it particularly attractive to Sun, particularly when they would have grave reservations surrounding licensing arrangements.
In any case, recent addition of non-support is irrelevant. cPanel has supported MySQL(tm) for years and years now, including having a barrel of tools that depend on MySQL(tm).
That's the primary reason, as far as I can see.
Ummm... no. MySQL does not have user-defined data types, object-relational extensions, full support for the CHECK constraint (a big one IMHO), views in a stable release, updatable views, rules, stored procedures in a stable release, synonyms, support for more than one autoincrement column per table, automatic conversion of code pages between client and server, nested transactions, complete trigger support, access privilege grouping, access to multiple databases in one session, multi-master replication, gateways to other DBMSs, XML data and transformation tools, and better tools for recovery from failures.
Actually, as of somewhere between 4.0.x and 5.1, MySQL(tm) does gain "enough" functionality to be able to (in some sense) support the operation of THE "enterprise system," namely SAP R/3.
It was interesting to watch the presentation by the MySQL guys at OSCON last month; I think that at some point they actually did mention that they had introduced all of the functionality actually required by SAP R/3.
Note that SAP R/3 does not require:
R/3 does all of those sorts of things (as much as it does them) in the application, that is, in the several gigabytes of ABAP/4 code.
In principle, I don't think there's anything that was needed to support "enterprise software" like R/3 aside from the introduction of the InnoDB transaction manager.
You may want to object and say, "Oh, but I mean for developing NEW enterprise software, not stuff written for IMS back in the 1970s."
To which my response would come in two parts:
A year ago, I was puzzling over the MaxDB deal; the only scenario that made any sense about it was for this to represent an opportunity for MySQL AB to, by supporting MaxDB for a while, to figure out the exact minimum set of features that they need to add to their own product in order to attract SAP AB's interest the next time they feel the need to rattle sabers at Oracle over licensing fees.
Considering that this is a route into playing high level games with some of the biggest "totally proprietary" vendors out there, that should cause concern for anyone in the free software community...
Database transaction logs are a good example of this; the cost of a transaction is normally:
The benchmarks suggest that the "writing out" part may be about 6 times faster; they tell nothing about what the impact will be of dropping seek time from several milliseconds to, essentially, zero.
Anything that involves a disk round trip with a seek can see an immense improvement. That certainly includes:
- Transactional databases
- Possibly nontransactional databases
But in general, what is most helped are things you update a lot . It won't be materially better than having more RAM for cache for anything else. It will be stupendously better than RAM cache for things that you want to quickly fsync() to disk.