MySQL to Counter Oracle's Purchase of InnoDB

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.'"

Comments

It looks bad, but...

[lifterx]

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.

InnoDB

[damiceious]

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?

Re:InnoDB

[fbg111]

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

[linuxhansl]

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.

Re:InnoDB

[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.

Silly

[jimmyhat3939]

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

Re:Silly

[wenzi]

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 know what they will do until they actually plan to do.

Re:Silly

[Dual_View]

That's the whole point. They're databases, and that's where the common ground stops. "Apples and oranges", is the phrase that comes to mind. They cater to different subsets of the public. Right now, this "competition" of theirs is just a self-imposed illusion.

Then again, you bring up another good point in and of itself. It's very likely that both MySQL and Oracle are looking at each other and considering how to market to the other's primary segment of clients.

But also, both databases are open-source. This should make things even more fascinating, unless the open-source community itself starts taking sides.

Re:Silly

[einhverfr]

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.

Re:Silly

[scott_karana]

As a database newb, may I ask what the problem with not distinguishing empty strings with NULLs is?

Re:Silly

[Master of Transhuman]

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.

Re:Silly

[Baricom]

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.

Re:Silly

[fbg111]

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

[jadavis]

MySQL and Oracle compete like public transportation and the automotive industry[1]. They're different concepts used in very different ways, so they are not direct competitors like Ford and Chevy. However, one is still an alternative to the other, so they are indirect competitors.

In some ways indirect competition is more destructive because it's a positive feedback system. The auto industry takes off in the U.S., so we build lots of infrastructure that make cars more desirable, which means more cars are purchased. However, if one person purchases a Ford that doesn't reduce the desirability of a Chevy to someone else.

That extends to databases easily. For the sake of argument, let's say MySQL users tend to put more code in the applications, and less logic in the database than Oracle users. Then their application no longer has much need for Oracle, reducing the desirability of Oracle, leading to (perhaps) another application built upon the same database system.

[1] I am making a very loose analogy. If you're trying to figure out which database I'm calling public transportation, and why, you've already put more thought into this than I have.

Re:Silly

[QuietLagoon]

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 from underneath Oracle's position.

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

Re:Silly

[barryvoeten]

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 job. But remember: garbage in, garbage out.

Re:Silly

[Eivind Eklund]

The problem with NULL is that it doesn't fit into binary logic. Both

0 < NULL

AND

0 > NULL

is false.

This mess up a bunch of logic.

For your case above, I'd code the answers something like this:

CREATE TABLE answers (
question_id INT UNSIGNED NOT NULL REFERENCES questions(question_id),
answer INT UNSIGNED NOT NULL,
user_id INT UNSIGNED REFERENCES users(user_id),
PRIMARY KEY(question_id, user_id)
);

An answer is represented by a row (question_id, user_id) existing, lacking information is represented by the row not existing.

Eivind.

Re:Silly

[arkanes]

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).

Re:Silly

[fbg111]

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 db means that every app that connects with that db is forced to adhere to the same constraints, so that even if the app developers on one particular app screw up and forget to validate a particular input field correctly, the bad data is still prevented by the DB's constraints. The DB will throw an error and the app will fail on the insert, and good developers will build into their apps try/catch logic and other methods of gracefully handling such errors. The DA and DBA's job responsibility is maintaining and ensuring data integrity, and building the constraints into the DB is the method of assuring that. In a nutshell, there should never be 'garbage in', and hence no 'garbage out' either.

MySQL needs to build their own storage engine

[Java_Good_COBOL_Bad]

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.

Re:MySQL needs to build their own storage engine

[jadavis]

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 (where the commands function as you might expect).

Re:MySQL needs to build their own storage engine

[Master of Transhuman]

The problem is that if you are developing a database with multiple tables related to each other (MySQL DOES want to be considered a "relational" database rather than a mere "file handler"), then you have to have referential integrity (or waste time coding referential integrity yourself - I used to do that with FoxPro back in the day, and it's not fun.)

Most of the MySQL engines don't do referential integrity - which makes them worthless for most "real" database efforts. Only InnoDB enforces foreign key constraints.

If the current version of InnoDB in MySQL 5.x is under GPL, and MySQL AB can continue to develop their own fork, it may not be that big a problem. But if they can't, due to patent or other IP issues, MySQL is in big trouble. In fact, for any serious uses, they're history, and everybody would be advised to turn to PostgreSQL or Firebird - or even Ingres.

Firebird in particular is fast and small and would suit the sort of Web applications that MySQL is known for - except that there isn't much support in Firebird for that sort of thing - but it could be added on if people see the need due to MySQL becoming a liability.

Other storage engines compared

[NickDoulas]

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) compare?

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

Re:Other storage engines compared

[einhverfr]

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 :-)

Re:Other storage engines compared

[TheRaven64]

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.

Re:Other storage engines compared

[hritcu]

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/) 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.

Re:Other storage engines compared

[einhverfr]

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, BDB is not a viable alternative due to backend issues. This is why the table handler is not actively maintained-- because BDB, as great as it is, was not designed to be a backend storage mechanism for a high concurrency RDBMS.

BTW, InnoDB has a table bloat problem (in that it has trouble removing dead tuples) which can be quite serious if you have a lot of updates or deletes. So for some sorts of installations, InnoDB might eventually have more serious performance issues than BDB (imagine PostgreSQL without vacuuming the DB).

PostgreSQL 8.1 avoids all these issues. The RDBMS is integrated with an autovacuuming capability, avoiding the bloat issues with InnoDB, and it avoids the page locks you have with BDB.

For those who are wondering, in a page lock, a page of data containing a number of rows of data is locked until the transaction times out. This essentially locks all rows stored near the row that is updated.

The real problem

[einhverfr]

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.

Re:The real problem

[einhverfr]

Exactly. What do you think *I* use? Hint: It starts with a P.....

This being said, I think that this discussion is important because it helps clear up *why* this acquisition is so bad for MySQL.

There are some other things that bother me about this response:

1) It took so long to occur.
2) No specific details. So this is entirely vaporware as far as I can see.
3) There are *no* alternatives to InnoDB on MySQL (BDB has performance issues, etc).

Re:The real problem

[ComputerizedYoga]

technically superior, sure.

But ... umm .... what's the word I'm looking for?

Oh yeah. Slow.

MySQL's got three big great things going for it: raw disgusting speed, relative simplicity to set up and administer, and the whole dual-license thing. Oh, and with innodb and with the 5.0 release, very nearly everything in the "technically superior" category (as far as most people are concerned) is covered. A lot of the things people bash mysql for are really complaints about the shortcomings of MyISAM instead. Oh, and don't forget that SO many websites and open source tools are built on top of the LAMP stack... and people wonder why it's talked about so much? Really, what's not to like?

Postgresql has relative simplicity to set up and maintain, but I don't think is quite as straightforward as mysql. And, as far as I've been able to tell, the speed just isn't there. We all love BSD licensing, and it still has some technical strengths over mysql, but the biggest issue is still speed, and all the benches I've seen still put mysql ahead on that one. (Besides, who's ever heard of the "LAPP" stack, and does it have something to do with strippers?)

Oracle, on the other hand, is already pretty fast and scalable, but non-free, non-f/oss, and generally an order of magnitude or two more complex to set up and maintain. In an organization large enough to have a dedicated database administrator, it's great, but it's not really suitable to be the database behind something like my weblog, or behind a small business's basic website.

Re:The real problem

[jsonn]

Update your facts. There are exactly two areas where MySQL is noticable faster than PostgreSQL. Those are connection time and non-transactional queries. If you depend on the former -- rewrite your programs, they are bogus. If you depend on the second, pray that the load will not increase enough to kill your database either by inconsistencies or locking. As soon as it comes to complex queries, PostgreSQL runs circles around MySQL.

MySQL 5 is still lacking a lot, most importantly in the I of ACID. It does not ensure integrety, it does things behind the scene which do not match the SQL commands. Silently trunkating data is evil, just like creating invalid dates. No excuses, MySQL just sucks in that department. Besides, stuff like the query cache don't belong into the database server. They belong into the middleware, since that is exactly where the necessary context is.

Last but not least, I do consider PostgreSQL to be much easier to administrate. I have central authentication support, I don't need magic commands to update the internal state of the server etc. It just works.

The LAMP argument is useless. Neither is PHP often a good choice for good web programming, nor is Apache necessarily the best web server. Just because a lot of people ask for it, doesn't make it good. You know the most popular Operating System out there, don't you?

Re:The real problem

[rbanffy]

The single biggest problem with the MP part of the LAMP stack is that both PHP and MySQL attract the wrong kind of developers.

The developers who are willing to live with the shortcomings of PHP and MySQL should consider if they really want to develop software. They are just like the people who are willing to live with the shortcomings of VB6 and Jet databases - they live with them because they know nothing else. While the query language of MySQL has improved with the latest releases, it is still not quite on par with, say, PostgreSQL. Do a somewhat complex join and you will see MySQL's speed go down the drain. See what happens when you have lots of concurrent long-running transactions.

MySQL screams "cheap" since its beginning and no amount of engineering will make it look well built. It may look "overbuilt", at best.

Re:The real problem

[LDoggg_]

That's an interesting take, but a little unfair.

Many people use LAMP because you can get a website hosted for next to nothing using it.
Most of the really cheap places I've seen offer either win32/asp/IIS/sqlserver or LAMP.

There are plenty of things I don't like about mysql 4.x (no sequences, no subselects, etc.) and plenty of things I don't like about php 4.x (lack of type hinting on primitives, no standard DB connectivity layer, etc.). But the workarounds aren't really that bad.

I could be much more productive with J2EE and oracle, but I'm not gonna get someone to host my sites for just a few bucks a month.

Re:The real problem

[llefler]

MySQL's got three big great things going for it: raw disgusting speed, relative simplicity to set up and administer, and the whole dual-license thing.

From my perspective, MySQL has two things over Postgres. MySQLAdministrator and they don't do silly things with case sensitivity.

OTOH, they only have one advantage over Firebird, MySQLAdministrator. I keep hoping that the guys over at "Firebird - Relational Database for the New Millenium" will wake up and get some good tools out there. If FlameRobin ever matures, I'll wipe MySQL from my systems in a heartbeat.

What's not to like? The job of the database it to maintain data integrity. MySQL falls down in a number of ways. Who cares what license it has if your data isn't safe.

Speed has never been an issue for me, but then, I'm not trying to use my workstation from two generations ago as a database server.

Re:The real problem

[jadavis]

I meant that I didn't know how it differs from the standard double-quote. Backtick seems to do the same thing as what the standard says a double-quote should do, so why don't they use the standard?

That's what seemed silly to me. I'd be interested to hear the reason for the use of backticks versus double-quote.

Re:Not silly at all

[jimmyhat3939]

It turns out that configuration is a difficult task and so there's no way to obfuscate that from the DBA.

Also, there exist plenty of situations where there are absolute tradeoffs. Making something fast in one case makes it slow in another. While it would be nice for the DB to be able to figure all that out beforehand, in practice it's impossible.

Take a case where a bunch of precomputation is required to make an operation fast (a particular kind of indexing, for example). You have to instruct the DB to do that precomputation. It can't know in advance that you'll be doing a lot of queries that require it.

Bottom line is that, though the goal of SQL is to make the "how" hidden from the user, in practice this is impossible and not even desirable.

Re:What is it with technology and cutlery?

[bersl2]

-1, Sporkless

Re:Not silly at all

[Master of Transhuman]

Actually, neither one of them implicates relational theory properly. Aside from the InnoDB engine, most of MySQL is pathetically incomplete. Without InnoDB, MySQL is worthless with regard to referential integrity, which is a showstopper for any database that requires multiple tables related to each other.

If the company building the Trans-Relational database ever gets off the ground (or failing that, goes open source), perhaps both of them (along with Sybase, SQL Server, Informix, and the OOP DBMSs) will be put out to pasture. The claimed capabilities of that system, implementing a very relationally complete system, would bury even Oracle eventually, if not immediately.

Anybody have any real background info on why the company developing the Transrelational system is having legal and/or financial trouble? Nothing concrete appears to be available on the DbDebunk site or via Google. The whole thing appears to have been hanging fire for a long time.

The name of the new storage engine is...

[adnonsense]

MyFireGreSQL.

Re:Not silly at all

[StrawberryFrog]

database that requires multiple tables related to each other.

That means, "any database" pretty much.

The claimed capabilities of that system, implementing a very relationally complete system, would bury even Oracle eventually, if not immediately

I don't think anything short of global nuclear war could "bury Oracle immediately". The installed base of very big DBs on Oracle is just too large.

If the company building the Trans-Relational database ever gets off the ground...

Does anyone have links or insight on this "Trans-Relational database" that I've nevre heared of, why it's so much better at "relational theory" than Oracle, why this is such a winner?

Oracle are now offering a free version of their DB

[philj]

In case you didn't know, Oracle are now offering a free version of 10g: Oracle Database 10g Express Edition

Indexing component is key for performance

[aharth]

From experiments with my database-like system in Java (http://sw.deri.org/2004/06/yars/yars.html), 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 replacement for InnoDB.

Re:Which Database?

[dkf]

postgresql->oracle is the best combo in the book. Every project my company has touched in the last 7 years started with postgresql and if we ran into one of the limitations in postgresql, switching to oracle was painless.

I'd agree with that, and point out that SQLite is there for people who come in at the small end of PostgreSQL. I'm told (by the SQLite author no less) that upgrading to postgresql is easy when you want to take that step. And it is public domain.

Between them, sqlite->postgresql->oracle offer a full database solution for everything from "I want a better config file for my personal scripts" to "I have to run a mission-critical database for a Fortune 500 corporation", and you can't say much fairer than that.

Re:Patent Threat

[joto]

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.

Original reasons for using MySQL replaced by...

[Anonymous Coward]

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.

Re:Not silly at all

[joto]

From my readings in the relational data model and RDBMS theory, I learned that SQL is supposed to be a declarative lanuguage, which means, you tell the DBMS engine what you want done, and not how?

Yes, that's RDBMS theory.

Then the DBMS will use the path which is most optimized for the request.

In the real world, there is no such thing as "most optimized". Optimized for what? Reliability? Portability? Correctness? Features? Code maintenance? Speed? Memory usage? Disk usage? Throughput? Interactivity? Uptime? Least sysadmin work? I could probably go on, but I think you get the picture...

So, the fact that MySql is better for some tasks than Oracle, is a flaw in both engines, and supposedly one that both are working to fix.

Yes, but that doesn't mean that it's ever going to be fixed in either of the engines. The fact that buses have more space, and bicycles are easier to park, doesn't mean that one day we will have something that combines the advantages of both.

Just to give an example, since the user, doesn't see where and how his data is stored, Oracle for example, can use MySql's engine internally, when it detect situations for which MySql's engine is optimized, and switch to Oracle's engine, when the situation change, all hidden from the user, of course this is all in theory. It can be factually impossible to implement such a thing.

Just like it's factually impossible for the bus to use the bicycles internal engine when you decide it's time to find a parking spot.

Re:Oracle are now offering a free version of their

[IANAAC]

Free? I can't seem to find the GPL source anywhere.

Different kind of free. You do know there's more than one kind of free, don't you?

Anyway, Oracle XE is actually pretty nice, particularly if you want to throw together a quick web-based app. I wish I could put something together with PostgreSQL/PHP (or whatever) as quickly as I could with Oracle's web forms designer.

Don't think so

[A nonymous Coward]

GPL prevents redistribution, not use. Companies only need to buy the commercial MySQL license if they want to distribute closed source programs. Internal usage doesn't care a whit.

Re:Which Database?

[ajs]

I've watched dozens of projects in a handful of companies move from other databases to Oracle. These other databases have included Fame, Sybase, BDB, MSSQL, MS Access, MySQL, Postgress, PostgreSQL, Ingres, and a variety of lesser known databases.

NEVER, have I seen such a project which I would refer to as "painless". Oracle is a monolithic beast which requires constant care and feeding by experts who have been so steeped in its ways that they are prohibitively expensive. Oracle perpetuates this situation and, as best I can tell, deliberately obfuscates their product in order to continue to rake in huge fees for training and services. Mind you, I've done Oracle DBA work in the past, so I'm not talking through my hat, here.

I would never, ever rely on Oracle. I use it as a bargaining tool in project management ("if we hit a wall with PostgreSQL/MySQL/etc. we can always switch to Oracle"), but unless there is a practical reason such as customer requirements which cannot be altered by me, I dodge it, and I would suggest that others do the same.

This has nothing to do with petty in-fighting about what feature-set is better. This is about a company that makes its money by abusing its customers. Why would you stand for that, even if it means giving up some feature, or working harder to implement some feature with a different tool? I would rather hire 5 MySQL or PostgreSQL engineers that work on expanding their feature-sets full-time, than pay Oracle a licensing fee.

Re:Which Database?

[kpharmer]

> With Oracle's purchase of Inno-DB and their recent release of a free version of their database software,
> it looks like a war will be shaping up over the low end of the database market.

I think you're completely right there - the big vendors know that the little databases generate cash too - and mindshare. They can't afford to lose it. This is a market-protection plan for them.

> Besides for being open-source, what advantages do PostgreSQL and MySQL have over Oracles' 10g Express,
> Microsoft's SQL Server 2005 Express, and IBM's proposed DB2 Express?

Well, MySQL is tarnished for a few reasons now:
- future is uncertain due to innodb buy-out
- history of inexplicable data quality and exception handling issues
- dual-licensing complexity

Postgresql is looking much better now:
- they had some performance problems 3-4 years ago, but are now well-beyond that
- is completely free
- starting to get picked up within very large commercial applications

In comparison SQL Server express and Oracle express offer:
- a free database for very small applications
- the opportunity to deploy a tiny database, then replace it with a larger one without any application code changes
- opportunity for vendors and shops to reduce the number of supported databases

DB2 Express offers:
- a low-cost database (last I looked it was around $750/server)
- with much more scalability than sqlserver/oracle express versions:
    - no storage limitations
    - partitioning is included (via mdc)
    - just two cpus (don't know if they can be multi-core or not)
    - I think 64-bit memory is supported, but is still limited to 4GB

So, Oracle & SQL Server have one strategy (offer an extremely limited product for free), while DB2 has another (offer a slightly-limited product for less than or about cost of MySQL). IBM might change the DB2 strategy, but I hope they just add a extremely-limited free version, and keep the existing express version.

And this strategy works: I've got oracle, sql server, db2, postgresql, and mysql in our organization, and am standardizing on db2. When we get a small database it uses a cheap db2 license. This keeps my labor costs down (which are far more than the software costs). If it wasn't for the cheaper licensed versions I'd probably be putting all of the small databases on postgresql - and growing that skillbase within the organization.

Whistling in the dark

[ppanon]

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.

Re:Not silly at all

[MattW]

Actually, neither one of them implicates relational theory properly. Aside from the InnoDB engine, most of MySQL is pathetically incomplete. Without InnoDB, MySQL is worthless with regard to referential integrity, which is a showstopper for any database that requires multiple tables related to each other.

As the companies using this pathetic database have noticed, 99.9999% works just fine; especially when your application is aware that you don't have a foreign key constraint and yes, the data may be munged 1 time in 1 billion and need to be cleaned.

eh?

[Stu Charlton]

Oracle is a monolithic beast which requires constant care and feeding by experts who have been so steeped in its ways that they are prohibitively expensive.

I know multi-terabyte Oracle DBMS' that run the entire billing and customer systems for some major telecommunication companies are basically run by 2 or 3 people, and they also have a couple dozen minor multi-gigabyte databases to support.

Oracle requires very little care and feeding. It does have a lot of knobs available for twiddling if you need to tune it, but if you're constantly twiddling them, there's usually a larger problem (the application has design problems, your hardware is inadequate, your staff is twiddle-happy, etc.)

Oracle perpetuates this situation and, as best I can tell, deliberately obfuscates their product in order to continue to rake in huge fees for training and services.

Complete bullshit. Oracle is one of the most well documented databases out there. If ppeople would just take the time to read the Concepts manual and browse Asktom.oracle.com for a day, that would skewer a lot of the "mystique" surrounding Oracle.

You don't need training or P.S. to manage a large Oracle database, you just need someone with good technical chops, the willingness and time to experiement, and the ability to learn. But that seems like the criteria for any profession.