How Real Is The Open Source Database Fever?
J. Misael G. points out a NewsForge article on recent moves by some database vendors to loudly release (some of) their products as open source, asking the vital question "How much open source beer are these newcomers bringing to the database bash, or are they simply coming in and asking where the cups are?" (Slashdot and NewsForge are both part of OSTG.)
I'm curious why some submissions carry the disclaimer, "Slashdot and NewsForge are both part of OSTG." Can anyone shed some light on this? Just curious. :)
A blog like any other.
I don't see how it is going to pan out in the long term for some of these companies, though.
Jerry http://www.syslog.org/
who keep telling me, that they want their commercial applications re-written with an open source database backend like mysql. I never have the heart to tell them that unless they are actually are releasing the source code for their apps, that they need to purchase a commercial licence
Think you can program? Prove it @ the geek challenges
mysql and others will.
;) or french way...
grow a dependent base of users, 50K or so, then close source the project and start charging.
that's the american way
There's also the fact that Oracle has a real, proven track record of reliability and scaliblity. There are bunches of companies that run huge Oracle databases on mainframe-supercomptuer hardware that can't ever be down, not even for a minute, and have done so for years.
Can something like MySQL do the same? Well, I honestly don't know. However if you are in a position where there will be extreme losses from an outage, you don't want to be the one to test and maybe find out that no, indeed it can't.
Oracle products have a place. They are expensive because of what they can do and how they can do it and they are very much worth the expense to those in the position that need them. MySQL should not be compared to the Oracle line but that doesn't make MySQL bad. It's just different.
You'll have that sometimes...
It's certainly true that Oracle can sell into the corporate environment using arguments like this (company X uses Oracle to manage a three terrabyte database! And they only accept one picosecond of downtime per decade otherwise all the DBAs get disembowled with a spoon!) - mostly in the hopes of triggering some mid level IT manager's penis envy. In practise, reliability is more a function of how good your people are than what products you use - guru + MySql > idiot + Oracle any day of the week, for 99 out of 100 common cases.
This isn't Oracle bashing btw: i've got MySql installed on my workstation because all the demo apps seem to use it, but i work on Oracle - TOAD is *always* open - and i've always said that if it could cook i'd marry it.
#!/usr/bin/english
<Off-topic rant>the editor of Newsforge really needs to have a word with the author of the article, I say. It is really not necessary to write "so-and-so said" in every single sentence, says me. I say that you only need to mention who said the words when the author/speaker changes. I say that it is very annoying to read that article because of the poor way that it is written.</rant>
flossie
Write now. Defend liberty
In that case, you might be interested in the opine-it extension for Firefox.
flossie
Write now. Defend liberty
> I don't think a company would hire an idiot to admin an expensive tool like oracle.
oooh, I *so* wish that you were right. But it assumes that managers have more choice over staffing, outsourcing, as well as more knowledge of technology & people.
Nope, I've seen *tons* of idiots in charge of oracle databases. And the odd thing is - Oracle especially is so very unforgiving.
But you can usually spot the idiots a mile away - big circles under their eyes from fixing the things they are constantly breaking, small jobs take 8 hours since they can't write a script - and need to interactively modify 400 database object, etc, etc.
Also keep in mind that many very large companies have site licenses for products like oracle, db2, websphere, etc, etc. So - they use the big product for every application. And this makes sense - it's much easier to manage and develop expertise for just Oracle than for a frankenstein collection of a half-dozen databases.
And the less important ones should (theoretically) be where your junior dbas learn the ropes. But it all breaks down with bureacracy...
There's also the fact that Oracle has a real, proven track record of reliability and scaliblity.
And they have good documentation and support...but their installation software is a piece of shit. The only people I ever knew to really get Oracle up and running smoothly were admins with years of Oracle experience.
-- "Makes Little Debbie look like a pile of puke!" - Moe Szyslak
Ingres and Cloudscape are clearly orphanware where CA and IBM clearly saw no need for the database management systems.
I work for CA in Ingres support. I can tell you that that statement is absolutely untrue. Every CA product that requires a repository or database of some kind either already uses Ingres or is in the process of being ported to use it. It's ridiculous to suggest that we'd 'abandon' software that's going to be at the heart of virtually every other product and service we sell.
> That's exactly the reason people should stay away from Oracle. Simply because it backs you into the
> product in a way the conversion is extremely painful and expensive. conversion from MySQL to
> MS-SQL or a similar SQL complient database is really pretty simple. Oracle is the mongrel out
> there and should be put to a very public open sourced death.
Funny, I don't have major problems on a typical migration between oracle/sqlserver/db2/postgresql. Oh sure, there are sometimes issues - differences in locking strategies, differences in partitioning, and differences in stored proc capabilities. Those three are the primary areas. But most of the time it's a nit. And of the major commercial databases - oracle has the least respect for standards.
However, Mysql very visibly defended the notion that 99% of the developers didn't need transactions, views, stored procs, subselects, unions, triggers, etc. Until very recently most of these capabilities were missing (even though oracle supported them almost 25 years ago).
Most mysql databases out there today still don't have transactions - and the applications that use them are often excessively complex due to poor legacy functionality in mysql. So, you often end up with 1000 lines of php & five queries in mysql when 10 lines of php and one query would do the job in any other database.
There's a lot of reasons to avoid oracle - its cost, Larry Ellison, oracle sales staff, its complexity, Larry Ellison, its low regards for standards, etc, etc. But the problems porting with msyql - are generally the fault of mysql ab and nobody else.
And until MySQL offers a full feature set nobody should be surprised that migration can be more expensive than necessary. And even then, if your database is going to get really huge - you'll probably want to think in terms of data architecture that go completely beyond what mysql has to offer (even at 100% Ansi-92 compatibility): and your application and overall architecture will be designed with parallelism, clusteroing, replication, partitioning, etc as part of the design.
And then you'll be able to reliably provide fabulous performance while casually slinging millions of rows around at a time. And it'll work great. No surprises.
That's why you sometimes *should* start out using oracle, db2, terradata, or whatever.
I contributed in a very small way to Wine (the windows replacement) development early on. In retrospect, I think that database products like Postgresql are going to be the next big open source wave. Licenses for stuff like Oracle can be very expensive. Also, it simply isn't going to take nearly as much to develop products that are highly SQL language and library call compliant with products like Oracle and SQL Server compared to the effort that has gone into Wine. The next big wave after databases are really done well will be I think the various accounting packages. This is an area where lots of shops want a degree of customization/tailoring.
MySQL is not really designed to do anything more heavyweight than lightweight content management (a SQL interface for NFS basically). It has data integrity issues which IMO should even rule it out of e-Commerce altogether or anything else where accuracy of information matters.
THese include:
0000-00-00 is a valid date in MySQL
NUMERIC types are agregated as floats which can lead to round-off errors.
Numbers are truncated if too large to be stored
(Strings are also truncated in violation of SQL standards, but this is not as severe as numbers for obvious accounting reasons).
If MySQL is unable to create an Innodb table, it may create a myisam one instead without raising an error. This creates a situation where you cannot be sure that your transactions are really being rolled back everywhere the application thinks they are rolling them back........
Now, PostgreSQL has no data integrity issues that I am aware of, and the few areas where it handles things in non-standard ways are clearly documented, and the core developers place a huge amount of thought into how to do things right. The level of professionalism in this project is truly amazing.
Firebird is nice too, but PostgreSQL has fewer limitations. These two databases are building the track record you speak of and they will continue to do so. Now with Slony-I, PostgreSQL has a decent, robust, and open source replication solution, I will expect continued interest in this area.
Oracle still has a few enterprise features that most of the open source databases lack-- table partitioning, grid computing (but investigate backplane if this interests you), and a few other options. However, on the down side:
VARCHAR's store NULL's as empty strings (which are not the same thing)(!!!)
PostgreSQL has much more flexibility in development due to the larger number of supported languages for stored procedures.
$$$
Licensing headaches....
Disclaimer: My company (http://www.metatrontech.com) provides solutions for MySQL, PostgreSQL, and Firebird. We will work with Oracle and SQL Server but it is not as much our things since we have an open source focus. We have been running PostgreSQL extensively and have only had problems due to hardware failure.
LedgerSMB: Open source Accounting/ERP
This enables you to use whatever database is on sale this week and even change your mind mid-stream.
I've said this before and doubtless I'll say it again it doesn't work like that in the real world.
Tell me how your app handles concurrency, if you've thought about it. An application optimized for performance with Sybase style locking will be crippled on Oracle and vice versa. Want to be completely generic? OK, accept that your performance will suck everywhere, and that your end users won't get a fraction of the value they paid for their database - and their hardware - and their developer's time.
People who pursue database independence are on a wild goose chase, and that's the truth.
Oracle is big, bad, and powerful -- fair enough. It's reputation is well deserved. It's also not a single application, but a conglomeration of applications, all of which need to be pursuaded to work together. Since the various limbs of the beast are developed by different branches of Oracle, they mature and are released at various times. Patches come out on an irregular schedule, and my overwrite previous patches, reintroducing old bugs or new incompatabilites. Trying to verify that version x of component a will play with version y of component b in environment c is enough to make one daffy. Babysitting this monster is time-consuming, and time is money. Trying to maintain more than a trivial deployment without tech support is (intentionally, I believe) a fools game. Draconian licensing terms and restrictions combined with the above factors make Oracle EXTREMELY expensive. The local branch of my company (200 employees) drops a tidy quarter-million into Oracle's coffers every year, and we get huge discounts.
I also maintain a few PostgreSQL databases. They're not quite as capable as the Oracle systems, but they can do at least 90% of what oracle can. They're much easier to configure and maintain, and offer very competitive performance. If we weren't backing oracle to the hilt due to manegerial fiat, they'd do nicely for the vast majority of our systems.
Other companies are leaving Oracle (and other big commercial companies) to lower their operational costs. As the open-source databases improve, a ever-shrinking group of companies are stranded on "big-$-database island" for technical reasons.
Oracle has people to pay and a bottom line to watch. As their market-share begins to shrink, how can they protect revenues? Hint: Look at their business strategy over the past few years. Here's the highlights:
- Try to improve the product. They're trying, but I'm not going to comment on what I think of the most recent efforts.
- Raise prices. Generates more revenue, but it's also fueling a race to jump ship.
- Unbundle products, and create "new" must-have applications, each licensed seperately. This is like going into
/usr/bin and distributing each tool individually, for a few bucks each (maybe with a few added switches to that you can claim "new and improved". No thanks, I'll write my own.
- Control the entire client life-cycle. Oops, I mean facilitate. Oracle has released a plethora of products (designer, developer, OAS etc.) to assist the developer, dba, application manager etc. This is like dealing crack. The apps, individually, aren't too bad (except for OAS, which basically wraps layers of nastiness around Apache to render it impossible to configure/maintain). The real problem is, once you take your first hit, it becomes virtually impossible to use standard tools to deploy, maintain, or version your app. For just a few dollars more, you can acutally use the app you've spent six months developing.
The business model centeres around squeezing more and more money from a shrinking pool of customers. I'm finding it increasingly difficult to recommend Oracle to any of my clients. Smart managers see the trap of vendor-dependance, and insist on open standards. Large database vendors have a vested interest in trying to `extend and extinguish` those standards, as Oracle is doing.I predict that, very soon, pointy-haired-bosses of companies that CAN move to open source will do so 'en masse. The software is stable and mature, all that's missing is corporate mindshare. As that happens, the only recourse the big vendors have is to squeeze huge amounts of cash from the handful of companies who really do depend on the few features not freely available -- an unstable and possibly fatal arrangement for all parties.
So, I'm working with oracle today, but looking for a good opportunity to jump ship.