OStatic

Web application development isn't easy. Part of the problem is that programs run on a number of different computers (i.e., browser/client, one or more servers, and one or more database servers). Part of the problem, of course, is cross-browser compatibility, which continues to give headaches to both programmers and designers. And part of the problem is that a Web developer needs to use several different programming and markup languages at once: HTML for markup, CSS for styling, JavaScript for programs that run on the browser, a server-side language (often one of Java, Perl, Ruby, Python, or PHP), and SQL for communicating with the database.

Of these, it is SQL that is most out of place. Many years have passed since SQL was first introduced to the world, and it continues to be the standard for database storage and retrieval. Just about anyone working with a database expects for it to be "relational," meaning that it consists of two-dimensional tables that can connect to one another. To communicate with a relational database, a programmer will typically create a query in a Web application, and then send it to the database. The results, sent from the database, are then parsed and used by the web application, with some of those results then displayed for the user.

The problem is that SQL is a completely different language from anything else that programmers use to build Web applications. (Well, aside from this very funny April Fool's joke.) Modern Web applications are typically written using object-oriented techniques, which don't map very well onto SQL's syntax or data representations. For this reason, there are object-relational interfaces, which allow a programmer to pretend (mostly) that the database is a bunch of objects. Behind the scenes, the interface translates the objects into tables. Ruby on Rails has become popular in no small part because of ActiveRecord, an object-relational mapper built into Rails, which handles many common cases with great ease.

Of course, there is another way to handle this problem: Perhaps we could write a database using objects, rather than tables. If we could throw out our relational databases (e.g., MySQL and PostgreSQL), and replace them with objects, our programs would be easier to write, easier to debug, and would generally be more coherent. This is a great idea, and there are some companies offering object databases. But for the most part, object databases have been too obscure or too slow for most purposes.

All of this is a way of introducing what I believe might be the biggest news to come out of RailsConf, which ended yesterday. Gemstone, a company that is best known for an object database and Smalltalk implementation, demonstrated something that they're calling "Maglev." As many other reports and blogs have indicated, Maglev is an implementation of Ruby that sits on top of Gemstone's Smalltalk engine. It's not obvious to me just how this implementation has been done -- but the it seems analogous in many ways to JRuby, which is implemented in Java.

What does this have to do with databases? Well, one of the things that Gemstone demonstrated at RailsConf was the ability of their Ruby implementation to speak directly with their object database. This database has been working for many years; it is very fast, highly scalable, and can handle huge (petabyte-size) amounts of data. If Rails were able to connect directly to the Gemstone database, rather than to a relational database, it would provide a bridge for many programmers curious about object databases, but unable to make the switch to this seemingly weird, different technology. In addition to being able to choose from among several different relational databases, developers would be able to choose an object database -- which, if Gemstone is right, would be both faster and easier to work with than a relational database.

Now, there are at least a few things to remember before we all go salivating over our keyboards. To begin with, Maglev is still a demo, not a real product. And as JRuby developer Charles Nutter pointed out, as Maglev approaches Ruby compatibility, we will inevitably see it slow down somewhat. Secondly, some or all of Maglev will be a commercial product; Gemstone has indicated that they might make their Ruby implementation free, but a license for their database might be quite expensive, as well as proprietary, which might not sit well with the open-source community. And finally, it's possible that despite the problems inherent in working with SQL from an object-oriented language, that it might take years for programmers to switch to something new and different.

The idea of a faster, more scalable version of Ruby on Rails is something that many developers would really like to see. Whether Gemstone will live up to the hype and expectations remains to be seen.

• rails
• ruby
• objects
• smalltalk