Slashdot Mirror
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."
Don't forget about PL/pgSQL, the procedural language for Postgres. This was written with Oracle converts in mind ;)
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!)
One problem with proprietary DBs is that their docs will steer you toward non-standard SQL even when standard SQL will work. For example, Oracle will teach you to use NVL and Sybase will teach ISNULL, when COALESCE works in both databases.
The solution is to develop with PostgreSQL regardless of what your deployment DB will be. Their docs favor standard SQL. The code you develop will work with the proprietary DBs as well.
Your DBA was running around tweaking all day because he was supporting a poorly designed application that was completely unoptimized.
Because so many developers have a notion (prominently displayed in this story) that "SQL is SQL" many apps running on a database run horribly inefficient queries that bog the database down.
Studies have consistently found that80-90% of database tuning needs to take place in the application. The database tuning portion mainly consists of tweaking memory and parallel query options.
Conformity is the jailer of freedom and enemy of growth. -JFK
The MySQL crowd just continues to remain ignorant of the fact that full SQL-92 support is not wanking, and it is certainly not a perf hit.
I must say I've gotten spoiled by the GUI that's available in Microsoft's SQL Server Enterprise Manager. It's damned nice.
I assume you've heard of/used phpmyAdmin, a PHP web application that reminds me alot of the interface to MSSQL Enterprise manager (though not as full featured, I'll admit). Anyway, it's something to check out if you're interested. Saves alot of time on testing and prototyping.
ttam
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
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.
Nobody seems to have noticed SAP DB becoming Open Source last year, but it too is powerful and reliable and includes full transaction support.
Got time? Spend some of it coding or testing