The (de)merits of proprietary databases

Posted Jan 3, 2010 20:59 UTC (Sun) by butlerm (subscriber, #13312)
In reply to: The ongoing MySQL campaign by robert_s
Parent article: The ongoing MySQL campaign

Make an open source Oracle clone that performs half as well Oracle does,
while maintaining basic Oracle compatibility and the world will line up at
your doorstep. I certainly would.

The "clone" part is important - to succeed, such a database should be a
drop in replacement for Oracle for most applications. Incompatibility with
Oracle's quirky null handling is the number one obstacle to moving
practically any good sized application from Oracle to PostgreSQL.
Compatibility with common little functions like DECODE() is another, and
support for Oracle's *much* superior outer join syntax. Lots of other
minor things, up to and including PL/SQL compatibility.

Now Oracle's dialect may not be the be all and end all of all things, but
what good does it do to have multiple competing SQL databases when each one
implements a completely different dialect with dozens of severe semantic
differences, such that you have to marry your database platform for life,
warts, deficiencies, evil licensing overlords and all?

The fastest way to *beat* Oracle is to be compatible with Oracle.

to post comments

The (de)merits of proprietary databases

Posted Jan 4, 2010 6:32 UTC (Mon) by ringerc (subscriber, #3071) [Link]

Standards. Aren't they great?

I agree there are a few places where Oracle's dialect is better than the SQL standard - 'CONNECT BY' comes to mind. The SQL standard is hardly an example of great design, and is full of bizarre warts.

In most cases, though, I find Oracle's dialect painful, and its differences seem like a mix of unnecessary historical anachronisms and deliberate customer lock-in. I'm not a big fan of its left outer join syntax - it's succinct, but that's about all it has going for it. DECODE doesn't appeal when compared to CASE. Many of its odd little functions are alternatives to standard ones with different names and/or parameters that don't seem in any way better.

Of course, many developers code to the Oracle dialect anyway, because they're used to it, they prefer it, or Oracle doesn't support the standard way of doing a particular thing. So I agree that in practice it's a big adoption barrier, much as supporting all those little MySQL quirks (AUTO_INCREMENT, REPLACE upsert statement, etc) would help. On the other hand, anyone who tries to keep on using their new database as if it's just the same as their old one will be doomed to poor performance and continual irritation. Such compatibility wrappers are really just porting aids.

EnterpriseDB tries to maintain Oracle compatibility. I have no idea how well they succeed, and would be interested in your comments. For performance, while Oracle is indeed rather impressive in many cases, you can get a lot out of Pg with the hardware you can afford from your Oracle license savings. Its lack of multi-master replication is its main scaling issue these days.