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)) |
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