Can mySQL/LAMP Challenge Oracle, Microsoft, and Sybase? @ JDJ
Conference in Santa Clara, CA, looks to be the biggest and most important gathering of the mySQL faithful yet. Those signed up for the conference are getting hit by at least an email a day, inviting them to stop by such-and-such a booth to see so-and-so's new product.
There are a lot of reasons for this, but the overarching one is the recent releases of two versions of the database program, giving it new features that make it much more palatable for database traditionalists and likely making it more welcome in IT departments. mySQL Version 5.0 promises more features that will likely make it more welcome in IT departments, alongside Oracle, Microsoft SQL Server, and Sybase SQL Anywhere. This in turn should further validate LAMP as a viable application development strategy.
The first release was that of version 4.1 a couple of months ago. The most notable new capability in 4.1 was support for subqueries, which allow one query statement to be comprised of several queries. Subqueries, and correlated subqueries are essential for creating sophisticated applications. Entire chapters of books have been written explaining how to get around the lack of subqueries.
Virtually every other SQL implementation supports subqueries. Without them, mySQL felt a lot like a toy. With the release of 4.1, you don't need to worry about that anymore.
But the really big step is the release, in beta form, of version 5.0 of the server. Version 5.0 finally adds support for several big features of relational databases: views, stored procedures, user-defined functions and triggers. Views let you create "virtual tables" that Can be addressed the same way as regular tables, but which comprise several different tables.
Stored procedures let you store sequences of SQL scripts in
one named procedure, which Can then be called from other programs.
User-defined functions allow you to use SQL to extend the language,
and provide shortcuts to complicated procedures. Finally, triggers are ways of programming the database engine to react to certain events in the database--inserting, changing, or deleting rows, for example.
Not all of these features is perfect. For example, functions Can not query tables, which places severe limits on their usefulness for such things as data validation in trggers. The implications of some features on such things as database optimization is not clear yet, either.
But the upshot of all these anguage changes is to add features to the server that bring it more in line with other big database products. As a SQL developer, I appreciated 4.1 a lot because it saved me time in having to write code that worked around limitations in mySQL itself. Using it was a liberating experience.
I look forward to 5.0's new features, for a lot of reasons. For one, it will remove the burden of scripting in the host language (I usually use PHP), and let me move some standard logic into the database layer of my applications. This means that I Can create standard interfaces in the database which Can be used from various host languages without having to re-invent the wheel every time.
mySQL will always have its skeptics. This is an area
where things Can get religious quickly. There are those who frown on features added to SQL by Microsoft, for example, and different points of view about what belongs in the database layer versus what belongs in the application layer.
But it's clear that with the imminent release of
5.0 in production, mySQL is here to stay. From the looks at the