Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Databases Programming Software IT

MySQL to Counter Oracle's Purchase of InnoDB 215

Posted by ScuttleMonkey from the corporate-chess dept.
Miff writes "Computerworld is reporting that MySQL is hoping to counter Oracle's acquisition of InnoDB by providing its customers with an alternative." From the article: "Axmark said the storage engine is 'pluggable,' meaning other storage engines can be substituted instead. He said the code for InnoDB is under the GPL (General Public License), so 'the code is always out there. It will always be out there.'"
This discussion has been archived. No new comments can be posted.

MySQL to Counter Oracle's Purchase of InnoDB More

MySQL to Counter Oracle's Purchase of InnoDB

Comments Filter:

  • It looks bad, but... (Score:2, Interesting)

    by lifterx ( 916661 )
    I think there's hope for MySQL. With Oracle's products becoming more affordable and the recent purchase of InnoDB it looks bad for MySQL but I think this could be there chance to become more independant of other companies.

    I think this could be the big push that they needed to seriously consider teaming up with the Postgres guys, which could be good news for everyone interested.
    • I think this could be the big push that they needed to seriously consider teaming up with the Postgres guys, which could be good news for everyone interested.

      What is your plan for that, and what do you expect the result to be?

    • The real problem (Score:5, Informative)

      by einhverfr ( 238914 ) <[moc.liamg] [ta] [srevart.sirhc]> on Wednesday November 23, 2005 @02:12AM (#14098494) Homepage Journal
      MySQL does not provide a transaction-safe store free of licensing overhead. Commercial licensing of BDB, SAP-DB, and InnoDB all require relicensing agreements.

      These being availble for use under the GPL and similar licenses helps out everyone who uses MySQL under the GPL. But it doesn't help anyone else out, including MySQL. What MySQL needs is the ability to add something like MVCC to a table type that they own. Oh wait that will never work because MyISAM should be pretty much at odds with the whole concept. I guess it is time to build one from scratch.

      So the inevitable outcome is that MySQL will probably have to write a storage engine from scratch that meets all the needs that InnoDB filled.

    • I think there's hope for MySQL. With Oracle's products becoming more affordable

      Oracle has never been in the business of providing affordable technology. I doubt that this "coming affordable" that you mention is something they are doing by choice. However, if Oracle can find a sneaky way to stop the competition ... perhaps they will be able to stop this process of becoming more affordable. Then, Larry Ellison can get back to having so much extra cash that he feels like a God!

  • InnoDB (Score:4, Interesting)

    by damiceious ( 819510 ) on Wednesday November 23, 2005 @01:51AM (#14098440)
    So, I'm not an expert on the GPL, but it sounds like we're looking at a fork? Where the OSS community gets to continue to use a public GPL`ed version, and Oracle will develop what they bought? I wouldn't think that Oracle would undermine MySql OS'ness, but the article said without a continuance of their license Mysql Development could slow down, or be setback. Maybe someone can explaint the highlights of the GPL that apply here?
    • This may not be about the GPL, but rather about patents. Reading the article:

      "if Oracle holds patents or licenses for the underlying technology such as algorithms or file structures, "then that could get quite interesting,"
      • "if Oracle holds patents or licenses for the underlying technology such as algorithms or file structures, "then that could get quite interesting,"

        I don't understand how these theoretical patents come into play.

        If Oracle already had patents on technology contained within InnoDB prior to acquiring InnoDB, they didn't need to acquire InnoDB. They could have challenged InnoDB's GPL licensing.

        If InnoDB contains patented technology that Oracle now owns as a result of their acquisition of InnoDB, isn't that a moo

        • Re:Patent Threat (Score:5, Informative)

          by joto ( 134244 ) on Wednesday November 23, 2005 @06:00AM (#14099076)
          If InnoDB contains patented technology that Oracle now owns as a result of their acquisition of InnoDB, isn't that a moot point since InnoDB already released that stuff under the GPL?

          No. Repeat after me: "patents have nothing to do with copyright!". Write it on the chalkboard 100 times...

          There could be patents covering the GPL-licensed code, which InnoDB might not have enforced. Of course, thinking in this way is almost paranoid, but it has happened before, remember GIF?

          No matter how GPL'd the code is, if it violates patents, it is illegal to distribute in countries where that patent is valid. If you doubt me, the text of the GPL license itself spells this out for you. And even if you already have a copy, unless it comes with a patent license, it's illegal to run as well.

    • Re:InnoDB (Score:5, Interesting)

      by fbg111 ( 529550 ) on Wednesday November 23, 2005 @01:57AM (#14098456)
      A few questions come to mind:

      1. Does Oracle need InnoDB? Would Oracle gain features or capabilities they don't already have by incorporating it into their database? If so, then perhaps we're looking at a fork.

      2. If InnoDB is forked, does MySQL have the developer talent to continue advancing InnoDB, or will the OSS community do it for them, or will it stagnate?

      • Re:InnoDB (Score:2, Insightful)

        by Anonymous Coward
        2. PostgreSQL has a huge lead here over MySQL, that is, as an community-driven open source project. They already have a large distributed network of developers, whereas I understand MySQL has been developed almost entirely by the AB.

        It will take a long time to reach the robustness of the PostgreSQL development project, and I bet a lot of people might switch at this juncture.

    • Re:InnoDB (Score:5, Interesting)

      by linuxhansl ( 764171 ) on Wednesday November 23, 2005 @02:13AM (#14098497)
      The issue is this:
      MySQL makes some of its revenue by selling non-open-source licenses to customers who, for whatever reason, do not widh to publish their contribution.

      Now, you can only release code under any license of your choice if you own all the copyrights.

      Once Oracle owns the copyrights to InnoDB (and if Oracle does not extend the same relicensing rights to MySQL that InnoDB did), the only option MySQL has is redistributing a derived work under the GPL, they are legally no longer allowed to release under any other license. This in turn cuts off one of their revenue streams.

  • Silly (Score:5, Interesting)

    by jimmyhat3939 ( 931746 ) on Wednesday November 23, 2005 @01:53AM (#14098442) Homepage
    I think this battle between Oracle and MySql is kind of silly. The two databases serve different purposes:

    • MySql is excellent for anything ranging from the casual user (a few tables, 1000 rows in each) up to fairly complex transactional work (a small or medium-sized company).
    • Oracle has a bunch of extra features, like an excellent fuzzy text search engine and certain optimizers for complex queries that MySql doesn't (and IMHO shouldn't) have. Oracle is the DB of choice for non-M$ medium-to-large databases.

    There are other differences. Setup and configuration of MySql is much simpler, and you don't have to go as crazy creating complex partition schemes on your hard disks to get decent performance. But again, that's as it should be -- for simpler projects you want the free alternative.

    --
    Free 411! 1-800-411-SAVE [1800411save.com]

    • Re:Silly (Score:2, Insightful)

      by wenzi ( 6465 )
      We won't know until we know what Oracle plans to do with InnoDB. Oracle is having trouble competing with MySQL. Look at the last realease that was free to use and deploy. They ( As does MSSQL ) have to compete withh MySQL.

      Oracle could repackage InnDB as a gateway db, with Oracle compatibility to get users hooked on an Oracle product that would later lead to sales.

      IMHO, Oracle does not need the technology, as Oracle has tons of capabilities. There is probably another reason why they bought InnoDB. We won't
      • Oracle's revenues are >1000 times Mysql AB.

        When Larry counts his $18 Billion I'm sure he'll call you for advice.

    • Re:Silly (Score:4, Informative)

      by einhverfr ( 238914 ) <[moc.liamg] [ta] [srevart.sirhc]> on Wednesday November 23, 2005 @02:24AM (#14098538) Homepage Journal
      FWIW, Oracle has had their competitive sights on MySQL for some time. In 2000 iirc, they started releasing migration path tools to help people move from MySQL to Oracle. It is within this context that I see the InnoDB acquisition taking place.

      (BTW, I don't like Oracle. Any RDBMS that treats an empty string and a NULL as equivalent should be avoided.)

      Oracle and MySQL compete in a number of interesting and important markets, and as we all know, application mandates have a tendency to grow as do datasets. So people see MySQL as a growing RDBMS and use it and sometimes get trapped into it by weird MySQLism's. This keeps people with the RDBMS when it is not even close to meeting real requirements and having to code around the deficiencies.

      Whether the markets overlap and to what extent, Oracle sees MySQL as a strategic threat.
      • As a database newb, may I ask what the problem with not distinguishing empty strings with NULLs is?

        • Re:Silly (Score:5, Informative)

          by Master of Transhuman ( 597628 ) on Wednesday November 23, 2005 @03:35AM (#14098706) Homepage

          An empty string is a value; a NULL is the absence of a value.

          In fact, in relational theory, according to Chris Date (although Codd himself supported the concept to some degree), NULLs shouldn't exist. This is because a table expresses facts - logical expressions - about an entity or a relationship, and a NULL is not a fact, it is the absence of a fact. An entity or relation about which you do not know the relevant facts should not be in a table which expresses facts about that entity or relation.

          NULLS also lead to screwed-up SELECT results sometimes and worse, sometimes you can't detect that the results are screwed up.

          This usually produces a religious war discussion, and I don't know enough to argue the case either way, so I won't say anything more about it. I'll just say that with Codd dead, Chris Date is the main man when it comes to relational theory, as far as I can tell, and he makes a good argument against NULLS.

          Pick up his book "Database in Depth" published by O'Reilly, which is not really a book for newbies, but does have some fairly clear explanations of the issues. It's smaller and cheaper (by about three-plus times - $30 vs $105) than his college textbook on the subject.
          • When representing the outside world, it seems clear to me that you'd need a way to represent something being logically consistent as missing, unknown, or unknowable. My height is 6 foot, my gender is male, my last gynecological visit is NULL.

            The argument is, perhaps that field should be normalized into a separate table of visit dates which does not contain an entry for me. That is the true NULL, that it isn't even present in the database.

            I think it's more design philosophy than an issue of right/wrong. Ther

            • Re:Silly (Score:3, Insightful)

              by arkanes ( 521690 )
              It may be accurate to say that while it is theoretically possible to design a database such that all data can be represented, and no nulls are present or required, the availability of NULL has real practical value (but Oracle making empty string be the same is still stupid).
            • My height is 6 foot, my gender is male, my last gynecological visit is NULL.

              There might be nothing wrong with this approach to your data model. After all, you can always search for gender to rule this out. The information is therefore present.

              However, it might make more sense here to break off this column to a separate table so you can track *all* gynecological exams of female patients (or for that matter any primary care visit of any patient). Generally if you have NULL's meaning "not applicable" this
          • This concept exists in Perl as well, as undef (an undefined value). This is treated as false, but is different from '0' or the empty string.

            The concept of no data is an important one, and should not be easily dismissed. I have read many arguments about why it shouldn't exist in relational models (needs to be normalized away, or whatnot), but most of the arguments fall down in the face of implementation considerations.

            Let me try an example. Say I have an application that needs to process data in CSV forma
          • In a purely mathematical sense, Date is correct in that NULLs don't fit into the math model of relational algebra terribly well. They are also overused which creates a tendency to have ambiguities in the interpretation of data (example: have a wage column for hourly earners and a salary column for salary earners. Does a NULL mean that you don't know the hourly wage or that the person doesn't have one?). But this is largely a db design issue and not an inherent issue with NULLs per se.

            The problem exists
          • If you do not use NULL, what do you put in say the maidden name of a man?

            I think that it makes more sense to use a null value than an empty string.
            • I think that it makes more sense to use a null value than an empty string.

              Why?

              How do you differentiate between a woman with an unknown maiden name and a man with no maiden name? If you don't do this then later when you need to do so, you will have ambiguous data in your db.

              You have two options here.

              You can split the maiden name column into another table where a NULL value means "Unknown" and no value means "No value" or you can use an empty space to indicate that the Maiden Name has no value in the table.

        • Re:Silly (Score:4, Informative)

          by Baricom ( 763970 ) on Wednesday November 23, 2005 @04:31AM (#14098858)
          The two value types can have different semantic meanings. Typically, empty strings signify that no value applies for the column, while NULLs signify that the value is unknown.

          Say you have a table with a MiddleName column. Using the rule above, if you store NULL, that means you don't know what the person's middle name is. in contrast, if you store the empty string, it means the person doesn't have a middle name.

          The distinction is controversial, and some database administrators feel that distinguishing between NULL and the empty string adds unnecessary complexity to an application.

          Disclaimer: While I'm confident that I know a little more about databases than the average developer, IANADBA.

          • I tend to use NULL to mean that I know that there is no value. Setting a field so that it allows NULL is like saying "not all things of this type have this property". Setting a field NOT NULL says that all things of this type DO or MUST have this property.

            This doesn't allow for "I don't know", but some would argue that you shouldn't be storing things you don't know about in a database in the first place. :)

            • I tend to use NULL to mean that I know that there is no value. Setting a field so that it allows NULL is like saying "not all things of this type have this property". Setting a field NOT NULL says that all things of this type DO or MUST have this property.

              But you have a problem doing this because your comparison sematics don't work for the meaning you are attributing to NULL. NULL tends to be used this way though and unfortunately it is an accepted practice :-(

              The problem comes from the following issue: W
    • Oracle has a good fuzzy text search engine? I'm not aware of it, but please point me to it.
      I typically use Lucene [apache.org] when I need to perform full-text and other IR-style searches on a data corpus.
      • It's a seperate product from Oracle (the company), not an integral part of Oracle (the database). I've used only very shallowly and other products even less so I can't speak to how well it compares with other stuff out there, but it's certainly more convenient than needing to interoperate with outside applications.
    • Oracle may not be being that silly. It is not that unusual to find Oracle used where its extra features are not needed, these are clients Oracle could lose to MySQL.

    • Re:Silly (Score:5, Insightful)

      by fbg111 ( 529550 ) on Wednesday November 23, 2005 @04:56AM (#14098901)
      It's a bit simpler - Oracle is for anyone who knows what data integrity is and requires it, MySQL is for anyone else. PostgreSQL is the free, acceptable alternative to Oracle.

      • Re:Silly (Score:2, Insightful)

        by barryvoeten ( 5508 )
        Us as technicians may perform this discussion. Parent has a point.

        Now, reality comes in. Get your end users to fill in the forms. Is that done properly ? As far as programs are concerned, they can do that, but, it is not their integrity we need a database for.

        Real-life integrity can only be obtained by estimating the integrity of the weakest part of the chain user-application-db. I suppose it's not the database that is critical in most cases. It leaves you to choose any db you think is reasonable for the

        • Re:Silly (Score:3, Informative)

          by fbg111 ( 529550 )
          But remember: garbage in, garbage out.

          True, but the purpose of the relational database is to prevent the 'garbage in' part. It relies upon the Data Admin or Data Architect (not the DBA, which is different) knowing the data in the problem domain thoroughly enough to design the database and its constraints so that garbage is not accepted, and the only data that goes in does so according to well-considered business rules and to the relational algebra of the model. Putting data integrity constraints in the

    • Re:Silly (Score:3, Insightful)

      by QuietLagoon ( 813062 )
      MySQL has been used very successfully on some projects that have Oracle very concerned. With MySQL 5.0's features, Oracle is seeing a competitor that is eating up the market [computerworld.com] from underneath Oracle's position.

      The key phrase to google [google.com] is "disruptive technology". Clayton Christensen is the expert on the topic.

      • MySQL is hardly a disruptive technology. Disruption implies "radically different". I question whether another RDBMS that happens to cost less and can be tinkered with is truly disruptive.

        And let's be clear. MySQL's database revenues were 0.01% of Oracle's in 2005 based on the Gartner and IDC surveys. Oracle makes in 12 hours what MySQL takes a year to make. And Oracle's growth is not shrinking at the expense of MySQL, not according to any statistics YET anyway. Perhaps it will happen, but a numb
  • It always seemed lame to me that MySQL users had to concern themselves with with "storage engine" gets used under the covers. The obvious answer from MySQL's perspective is to build their own storage engine as an integrated part of MySQL.
    • The problem is *not* that the storage engines are modular. That's an innovative implementation decision, and it is not inherently bad.

      What causes the problems for some people is the MySQL exposes a different behavior to the user for each storage engine. In other words, the storage engine is not abstracted away from the user, but just the opposite.

      Examples include foreign key and transaction behavior on MyISAM tables (that is, the commands are ignored by a MyISAM table) versus the behavior on an InnoDB table
    • Why not different storage engines? If you have a table that is rarely updated (like a lookup table) why not use a table type is optimized for reading? If you have a small table of disposable data why not use a in memory table type?

      It's a feature, maybe it's not useful for you but it might be useful for somebody else.

  • Other storage engines compared (Score:3, Interesting)

    by NickDoulas ( 555431 ) on Wednesday November 23, 2005 @02:07AM (#14098482)

    Does anyone know the practical difference in using other storage engines? For example, how does using Berkeley DB (http://dev.mysql.com/doc/refman/5.0/en/bdb-storag e-engine.html [mysql.com]) compare?

    Also, how typical are non-InnoDB configurations of MySQL?


    • Just use PostgreSQL and be happy. As soon as you start having to ask yourself questions about what "storage engine" you're using, or whether your transactions are really coherent, or start thinking maybe you really did need proper modern (OO)RDBMS features, it's time to drop the toy and start using the real option.

      • Re:Other storage engines compared (Score:5, Interesting)

        by TheRaven64 ( 641858 ) on Wednesday November 23, 2005 @06:46AM (#14099180) Journal
        A lot of things where MySQL is used really don't need a database. What they need is something like VMS's structured files - something slightly more abstract than an arbitrary stream of bytes, but not much. In these cases, SQLite might be a better choice than PostgreSQL, although I'd still recommend PostgreSQL to anyone who actually needs a database.
        • What VMS had was RMS, which gave you everything from unstructured files all the way through to b-tree based ISAM. The assumption on file types is massive OS dependency, but it means that applications on VMS tend to interoperate well. Unfortunately, no such thing exists on Unix. Sure I can use Berkeley/Sleepycat DB, but which version?

          MySQL is already overkill, but at least it is some kind of standard.

    • Re:Other storage engines compared (Score:4, Informative)

      by einhverfr ( 238914 ) <[moc.liamg] [ta] [srevart.sirhc]> on Wednesday November 23, 2005 @02:15AM (#14098504) Homepage Journal
      The BDB handler has been barely maintained. All the benchmarks I have seen show BDB losing out to pretty much every other storage engine. You get transactions and advanced capability, but at a huge performance cost.

      Use PostgreSQL and you will be happier :-)
      • The BDB handler could be updated, and I don't think that would be that much of a problem. As for Berkeley-DB itself it is (very) actively developed (http://www.sleepycat.com/ [sleepycat.com]) and it is surely more widely deployed and more stable than InnoDB (Berkeley-DB has 200 million deployments compared to only 5 million MySQL deployments). As for the "huge performance cost", I really doubt there is such a thing.
        • As for the "huge performance cost", I really doubt there is such a thing.

          Sure there is. BDB uses page-level locking while Innodb uses snapshot technology.

          This means two things:

          1: BDB has blocking issues in high-concurrency environments and is thus not suitable for a backend for a higher-traffic RDBMS.

          2: You can only support Read Committed transaction level. You cannot support Read Uncommitted, Serializable, and Read Repeatible because you lack the snapshot capability required to make this happen.

          So no, BD
          • Thanks for the explanations. So, from know on, just PostgreSQL for me, right? :)
            • Thanks for the explanations. So, from know on, just PostgreSQL for me, right? :)

              I don't know your requirements, but I would *certainly* recommend evaluating it.
              It has become quite easy to use, maintain, etc (which it was not 5 years ago) and has become even more powerful. As with all RDBMS's there is a transitional learning curve, but I have found it to be easier with PostgreSQL than with Firebird due to distributed documentation and high quality help on the email lists.

  • The name of the new storage engine is... (Score:4, Funny)

    by adnonsense ( 826530 ) on Wednesday November 23, 2005 @03:33AM (#14098698) Homepage Journal
    MyFireGreSQL.

  • Oracle are now offering a free version of their DB (Score:3, Informative)

    by philj ( 13777 ) on Wednesday November 23, 2005 @05:09AM (#14098931)
    In case you didn't know, Oracle are now offering a free version of 10g: Oracle Database 10g Express Edition [oracle.com]
  • From experiments with my database-like system in Java ( http://sw.deri.org/2004/06/yars/yars.html [deri.org]), I learned the hard way that the indexing/storage component is the key piece for any system dealing with large amounts of data. Performance depends to a great extent to the underlying storage mechanisms used (and different implementations of e.g. B+-Trees vary greatly in performance and functionality). Implementing a fast B+-Tree with transactions is a non-trivial task.

    Let's hope MySQL AB. find a good replace

  • Original reasons for using MySQL replaced by... (Score:4, Insightful)

    by Anonymous Coward on Wednesday November 23, 2005 @06:32AM (#14099147)
    When many people started using MySQL over other choices, the landscape was quite different.

    * PostgreSQL wasn't available in a native version on Windows and their developers were still mastering the codebase they inherited (they mastered it around 7.3, before that they tiptoed around making massive changes).

    * Firebird wasn't open sourced yet (before summer 2000).

    * and SQLite wasn't released either (before summer 2000).

    The above 3 conditions are no longer valid.

    Many of us use MySQL because so many other software packages are already designed to work with it. Like Windows, it doesn't matter even if better alternatives exist because this one reason alone is most compelling if the software is "good enough".

    In other words, the original technical reasons for choosing MySQL over others has been replaced by a compelling new reason: the same reason many people use Microsoft Windows today.

    In a nutshell:

    * If I want a super fastest lookup table without SQL, I'll use something like cdb or tinycdb.

    * If I want a fast and simple database requiring only a tiny subset of SQL, I'll use something like SQLite.

    * If I want a modern, full-featured, and free rdbms/ordbms, then I'll use PostgreSQL.

    * If I want compatibility with most 3rd-party software, then I'll use MySQL.

  • Whistling in the dark (Score:3, Interesting)

    by ppanon ( 16583 ) on Wednesday November 23, 2005 @10:51AM (#14100746) Homepage Journal
    He said the code for InnoDB is under the GPL (General Public License), so 'the code is always out there. It will always be out there.'

    That's true enough, and yet MySQL uses GPL for its free Linux version but a different licence for the Windows version, don't they? They can't just pick up InnoDB and roll it into their Windows release because they don't hold the copyright to be able to release Windows InnoDB under their Windows licence. So, if Oracle kills InnoDB (or starts increasing the price for non-GPL releases) MySQL might have to revisit its business model.

    I always liked PostgreSQL better anyways.

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close