Open Source Database Underdogs
implex writes "Interactive Week had an article called "Data Underdogs" which they compare offerings of present Open Source Databases with present commercial offerings. In one part they mention ...On the other hand, MySQL developers now have a much-needed transaction management system: NuSphere last month made its Gemini transaction manager for MySQL available as open source code on mySQL.org, a site that the company recently launched. Complicating matters, though, is NuSphere's blood feud with MySQL AB, a Swedish company that runs a competing open source development site for MySQL code at www.mysql.com. No mention of the fact that MySQL AB actually created the product was interesting."
Instead of focusing in on the available solutions, the article simply spits out the idea that MySQL and Postgres are weak pretenders.
The FACT is that these databases are excellent solutions to a large number for MOST database problems. Sure, like all DBMSs, they can always use more features. But I don't want my DBMS to turn into an uncontrolled monster like Oracle.
For 99% of the applications out there, Postgres and mySQL fits the bill. If you're doing large scale distributed payroll using SAP, then I suggest you go with a big name...
But if you're an average-sized business, Postgres is a full-featured solution today. It is an inexpensive, fully-capable solution.
If you're into writing Oracle PL/SQL, a proprietary procedural extention to SQL, go with Oracle. (Note: PL/SQL doesn't work with Sybase or DB2 or anything else.) If you're into TransactSQL, another proprietary SQL extension, go with Sybase. Once you get into TransactSQL, you'll NEVER migrate out without expense. In fact, my shop, an Oracle shop, doesn't PERMIT developers to use the PL/SQL ewxtensions. We learned our lesson after migrating from proprietary MS-SQL-Server extensions to Oracle!
And if you need a big company to support your 20,000 person payroll, go with IBM's DB2. Again, another fine DBMS.
But for the average shop? Save your money and go with PostgreSQL.
What's the problem here? We've got and open source database that's being developed in two somewhat different directions by NuSphere and MySQL AB ... seems like in the end it'll lead to two different, but each (for their intended applications) excellent products. I just don't see a problem.
Maybe I'm just being dense (first reply: "Yes, you're fscking dense!")
You are evil. OSS can accomplish anything ... well, web browsers are hard! ... I'm sure a database is easy though!
Actually, I've noticed a growing trend in the crowd of programmers I run with is not to care about the implementation platform.. SQL is SQL, and you don't do transactional based stuff on the platform anymore, you abstract away from that into your middleware, and do things the way you want to. In REAL LIFE programming, you often don't have the chance or opportunity to spec out what your back-end platforms are, you have to deal with what's given, or what's legacy at Company XYZ Inc. You also are often dictated a programming langauge for the project whether it be java, c, cobol, perl, python or whatever. The real value lies in being able to adjust to whatever the PROJECT calls for, and being able to implement on just about any platform you need with strong good design patterns. MySQL and Oracle both do exactly the same thing from my point of view, hold data in a relational format for storage and quick retrieval. Putting too much logic into the database only serves to slow things down in the long run. Nasa Switches from Oracle to MySQL shows us why Oracle putting all those bells and whistles in their product may lead to a weakening of their marketshare ultimately. The fact is, bells and whistles cost memory and processor, and there's a balance between the two that Oracle seems to be blithly ignoring.
No. The point is that the design of a great DBMS takes a lot more unity than the large-scale projects OSS has tackled previously. In a DBMS, there must be an internal set of standards for everything from datatypes to join optimization logic.
Databases just don't lend themselves to fragmented development the way operating systems do. Frankly, I'm skeptical that an OSS project could (using current development practices) pull together and produce something as capable and stable as DB2 or Oracle.
We did recently quite a bit of Perl development using MySQL and InnoDB tables, and they worked (surprisingly) well. Having transactions (finally!!) in MySQL is a huge blessing.
Somewhat related...while the article mentions that MySQL and Postgres don't have the large application development support infrastructures that the bigger commercial database have, they can be a lot quicker to prototype and develop with because of their relative simplicity.
We're in the middle of migrating our application to DB2 on RS/6000, and I have to say I'm missing MySQL's simplicity of administration and configuration...you can try out a lot of new ideas quickly with MySQL, whereas a big chunk of our time at the moment is spent poring over DB2 manuals for obscure command switches and SQL options (the LOAD utility can be a barrel of laughs for newcomers)...of course if our DBA was a little more competent, but that's a different story :-(
(And yes I do realise DB2 is much more powerful/robust...I'm talking about ease of development and rapid prototyping!)
Companies keep everything on database systems. Hundreds of geek-hours must go into the design of a database application for a company. Whatever system a company chooses, they must be reasonably sure the system will:
- almost never fail
- be supported by a stable company and
- integrate well with other systems, into the future.
A smaller price tag may be a good start to target smaller companies that don't rely heavily on database applications, but the reason Oracle can charge $15k/CPU for 9i Standard: the reputation is worth it.I only have experience (but lots of it) with Oracle and - unfortunately - SQL Server. Until SQL Server 6.5, I think it sucked compared to Oracle. But now they're more on level, although Oracle has always, and still does, handle huge data warehouses much better.
That aside, I worked for years with a 4TB data warehouse for a major credit card company. It was Oracle (7?) on a Sun E10000 (22 processors, 1GB ram) and it was screaming. We barely used any "advanced" features that were unique to Oracle. But what impressed me was Oracle's support. They had an office a few miles away and would send DBAs over to help out. Our DBAs were excellent, but when it came to very low-level tweaking, these Oracle DBAs knew their stuff. They would mess around with the OS to keep it as efficient as possible. And if there was ever any kind of failure or error, they came over to check it out.
Now granted, my company paid big bucks for the support, but at the moment that sort of support can't be found for an open source dbms. These were highly skilled experts in the database they supported. I realize (partly from the article) that the current goal of open source databases is to grow in the low-end market - smaller systems and such - and I'd bet they'd stand up to large warehouses. But one big advantage Oracle and DB2, and to a much lesser extend SQL Server, have is their support. You can have a highly skilled technician in your office very quickly if you need it, beyond the support of a consultant could provide. I'd like to see that kind of support in open-source companies. That's when I think they'll give closed-source databases a true run for their money... literally.
Developers: We can use your help.
"Databases are dramatically more complicated than any Web server or operating system technology."
The above is a quote from senior marketing director Bob Shimp, from the article. I will give him the Web Server - which is not to say that it is not complex, but likely not as complex as a robust relational database. I cannot do the same for the OpSys. There is a dramatic difference in the levels of complexity between a monolithic single-user non-multitasking operating system (such as DOS) and a multiprocessing distributed parallel asymmetric (etc etc) OpSys. The quote is not grounded in any sort of evidence, and I have serious doubts as to whether the 'marketing director' would have ever encountered a kernel that did not come from a bag marked 'Orville Redenbocker'. It is simply misguided and misinformed, and the general intent seems to be in undermining confidence in Open Source DBs. (... furthering the myth that open source is 'unreliable'.) Threatened? He likely should be.
I'd like to see an object data model (ODM) open source database come into the scene. Now that would cause a ruckus, challenging both the bottom line and validity of the relational model!
MySQL has two table types that support row-level locking and transactions. One is tied up in this contractual mess, but the other, InnoDB has no such issues, and may even be faster for many purposes.
Bah ! I remember in the early 80's when big iron buddies used to point ant laugh at dBase II. What they didn't understand, and what some of the big database boys and users don't understand now, is that larger isn't always better.
Databases like MySQL make it very easy for webhosting companies to offer free databases without loosing their shirts or minds. They make it very easy for students to learn SQL. They're also much kinder on resource.
Yes, I'd love to be able to roll-back pooched transactions, but then I have to commit everything as well. Certainly cascades would be slick, but poorly written, they can shoot your foot clean off. Likewise, I can see all the lame support calls coming in because users don't understand the triggers are attempting to maintain referential integrity on foreign keys.
Within a given context, sometimes smaller is suits the purpose better.
healyourchurchwebsite.com - WWJB?
If a database goes wrong (and in Oracles case, my experience is that that's often), and we can't solve it ourselves, we need to be able to get on the phone and speak to somebody who can help. Now, I know that there are companies that offer support for OS DBMS's, but Oracle, Sybase and IBM's round the clock support offering is what i'm after. and getting skilled technicians (possibly the development team itself) involved quickly. OK, so open source offers this as by merit of "use the source luke", but in a corporate environment, this is neither likely or necessarily sensible.
Another, and perhaps more important, aspect to bear in mind (and this is not covered by the article for obvious reasons) is that Oracle, Sybase and DB2 are not the be-all and end-all of RDBMS offerings. There are better, and often significantly cheaper, closed-source offerings out there. One of my current favourites (which I'm working with at the moment) is Clustra - a DBMS that offers 99.999% availability, scheduled and unscheduled, pretty much out of the box, with Linux as their first released OS for the latest 4.1 offering
So, in a nutshell - Open source support offerings need to be improved, but don't rule out the smaller fish in this crowded, and very competitive pond.
Who said databases were boring?
ooooooh! What does this button do? - DeeDee, Dexters Lab.