Virtuoso, Mono, and the future of data management

using System;
[Serializable]
public class Point
{...

create table CLR..Supplier (id integer primary key, name varchar (20), location CLR..Point);

insert into CLR..Supplier (id, name, location) values (1, 'S1', new CLR..Point (1, 1));

select s.name from CLR..Supplier s where s.location."distance" (CLR.."Point" (4, 4))
The inevitable unification of our various data-management disciplines -- SQL, XML, object persistence -- is a longstanding fascination of mine. For a glimpse of where things are headed, check out OpenLink Software's online demo of the new version 3 of its Virtuoso Universal Server. At this URL, you can see a live example of .NET CLR objects being stored in the Virtuoso database, and .NET methods being called on those objects from Virtuoso's stored-procedure language.

Here's the kicker. That demo server is either a Windows box with .NET, or a Linux box with Mono. I am not certain which, at the moment, is active.

Cool!

There are a million questions to ask about this idea, which is also (I'm told) central to the forthcoming SQL Server version called Yukon. For example: How will object storage and XML storage co-exist in the next generation of database engines? What role will remain for conventional stored-procedure languages -- and for that matter, given the strong Web services encapsulation that's evolving in the RDBMS space -- for stored procedures themselves?

It took a long time for SQL to get established. I figure it'll take at least as long for the new hybridization of data-management disciplines to work itself out. But I'm glad to see that it's happening. When asked recently why I think scripting languages such as Perl and Python are so important, I realized the answer had as much to do with the exploratory development of data structures as it did with the exploratory development of code. In scripting environments there's really no difference between those two activities. Imagine enjoying that same fluidity in the context of "real" databases!


Former URL: http://weblog.infoworld.com/udell/2003/01/28.html#a583