MySQL's had an interesting path lately, which I'd missed most of, as I'm currently working in an Oracle shop. Google released their patches for the database system, and several other companies (eBay, for one) have written their own sets of patches to improve MySQL for their particular purposes. That wasn't much of a surprise; it's open source, it's stable, and large companies can benefit from tweaking projects to fit their needs.
What got me were two related (but outside) projects; OurDelta and Drizzle.
Drizzle is a branch of MySQL, stripped to bare bones and optimized for multi-core, multi-cpu modern systems. It's specifically aimed at cloud computing, and (by default) turns off all of the enterprise features; triggers, stored procedures, views, and several other things are in optional plugins, and not part of the standard install. It was branched by a group of folks at Sun, working on MySQL, who believe the current system core can't be easily developed to be modular, and who wanted to make a very, very alpha branch to work in that direction. It's still very immature software, but their aim is to make the next great database, and seems to have good odds of doing just that.
OurDelta is a website barely five weeks old, but already with a lot of interest generated. Various companies have created and open sourced their patches to MySQL; this site aims to aggregate them all. Their aim is to make the very best of the current database technology, and it looks like a really good start, with 20+ patches built into 5.0, currently working on ports to 5.1.
Dunno if it's interesting to you, but it's interesting to me to see two open source projects aiming to solve the same problem by opposite means, with both showing measurable success.
MySQL Split
Worst Practices
I'm working on a project where the original authors of the code weren't competent with the tools they chose to use, or the tools that were chosen for them.
The technology involved is BEA Weblogic, Java, Servlets, JSP, HTML, JavaScript, MSSQL.
This is from 1999, and there's no real concept of MVC. Some HTML occurs in the Java instead of the JSP. Part of the business logic is in Java, but more than half happen as SQL stored procedures and functions. Cut-and-pasted blocks of SQL repeat the same task in multiple places with different variables, so if you find a bug in one place, it may be everywhere, and a quick search may not turn it up.
Several bits of that business logic appear to happen by accident. A variable may be returned from a multi-return stored procedure that has been set to a constant at return-time, or may be the value of an uninitialized variable in the SQL that's never used anywhere. Why these weren't set as constants in the Java object, I don't know.
Meanwhile, in using Java, they chose to use as little of the object oriented features as possible. Instead of having an employee, who has a first name, a last name, an id, and so on... they chose to represent groups of employees as rows in two-dimensional arrays with undocumented column names.
Nothing is commented. The primary language of the coders was not English, so the variable names I do have are often misspelled in misleading ways. The variable names in the database are truncated, and often misnamed for what they represent. There is no documentation of what any of the business logic is supposed to do.
The Java itself isn't archaic, it's written in a style I've never seen before. Today, I track back and find out the value of the variable mainPay is always "1", "2", or "3". I stagger across this:
if ( "1".indexOf(mainPay) > -1 )
else if ( "23".indexOf(mainPay) > -1 )
The database isn't normalized, and indeed, isn't planned by someone who understood relational databases. All numbers are stored as strings. Some of the numbers are padded with whitespace, and others aren't, and the distinction is both important and arbitrary. One column that I've found takes user input positive numeric data (1, 2, 3, 4, 5), and stores it as Roman numerals, space-padded to three spaces, but not beyond. However, if one checkbox on screen was selected, the column then stores the character 'Y'.
This is the second ugliest code I've ever worked on, and refactoring doesn't seem to be an option that the management will consider, as we don't have the manpower to do it. I now understand how Cobol was still a problem for Y2K, at least.
My working assumption was that this was done by a group of classic Visual Basic developers who were learning Java as they went, as a VB coder's thought processes would account for most of these problems. The software, given very carefully massaged input, is rock-solid, and I'm astounded every day at how hard these folks must have had to work to get this big of a turd polished to shine on the outside.
