views:

164

answers:

5

I was thinking many times, now days that we have Linq and other CLR language-specific built-in search, sort and other capabilities over tables, collections and object, why not have the 'SQL Server' or rather call it 'CLR Server' (not only OOP Server but CLR 3.5) which will be a CLR (or COM) DLL that exposes the data allowing users linqing right over it; this will save much of cuncurrency pain, time of developing in two different language and so on. I am not saying (god forbid) throw away SQL, it just crosses my mind to many times, I thought let's hear what the community has to say about.

This idea is not completely new of course, there is such (different than my idea tho) a DB in FoxPro. But I am talking about a pure CLR .NET 3.5+ DB that will allow external accessing the DLL, should not even generate SQL Queries, the whole system should work differently.

There should be additional Linq keywords for insert update and delete but they should all be 'Linq style'.

I am 100% sure that Microsoft have been thinking about this before maybe they had performance considerations and more IDK, let me hear your opinions, I personally think that today with .NET 3.5-4.0 if we will have collection handling, Extension methods etc. in the server treating all the data as object it might be really cool (regarding coding, again, donno what about performance).

Whatcha say? I hope this question was asked in the right place, please accept my apology in advance, if it does not belong to here, please comment and I will delete it.

Sorry for this poor example, but please get the idea:

Module Module1

    Sub Main()
        ClrServer.MyDataBase.ObjectContext.MyTables.Add(New ClrServer.MyDataBase.MyTable)
        Try
            ClrServer.MyDataBase.SaveChanges()
        Catch e As ClrServer.UpdateException
        End Try

        Dim x = From a In ClrServer.MyDataBase.ObjectContext.MyTables Where a IsNot Nothing
        Dim y = From a In ClrServer.MyDataBase.ObjectContext.MyOtherTables Where a IsNot Nothing
        Dim z = From a In ClrServer.MyDataBase.ObjectContext.MyFreakingTables Where a IsNot Nothing

        'So far no access to server made, the local maintainer hold up the request
        'Connection to server is going to be made in the next line
        'and previous 3 queries will be loaded then.
        ClrServer.MyDataBase.ObjectContext.Execute()
    End Sub

End Module

'This is server side code, there should be internal ways to connect to real data when executing.
Namespace ClrServer
    Namespace MyDataBase
        Public Class MyTable

        End Class


        Module ObjectContext
            Public MyTables As List(Of MyTable)
            Public Sub SaveChanges()

            End Sub
        End Module
    End Namespace
End Namespace

We could then import the namespaces and use the ObjectContext inline. Please do not say "bad code" cuz it is bad code, I only wrote a poor pseude example right in the Stackoverflow WYSIWYG editor just for you to see what I mean.

A: 

LINQ to SQL is an O/RM (object relational mapping) implementation that ships in the .NET Framework, and which allows you to model a relational database using .NET classes. You can then query the database using LINQ, as well as update/insert/delete data from it.

http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx

Robert Harvey
I wasn't talking about querying the DB with an ORM, I want the DB itself to be CLR based, no mapping, no connections, connection should be accessing a DLL, no need to maintain a DataContext, nuttn!
Shimmy
You did sort of miss the point of the question Robert. Though what you said is in fact true.
Matthew Vines
It took awhile to parse the question in the first place, I'm not surprised I missed the point.
Robert Harvey
+5  A: 

You are describing an Object Database. Here's one:

db4o C# Database

  • Native to .NET 2 and 3.5 (including the Compact Framework)
  • 100% Object Oriented Database, no object-relational mapping
  • Designed for embedded use in zero-admin environments
  • Open source and free under the GPL

http://www.db4o.com/s/csharpdb.aspx

Robert Harvey
+1  A: 

Would be neat, but having an extra abstraction layer between the object model and the data store allows for a lot of optimization. There's a lot of cool stuff going on inside SQL Server when you hit it with a query that would have to be reinvented if removing the SQL layer. I'm sure one day it will happen but not sure if there is enough benefits with it to justify something like that today... JMHO...

KristoferA - Huagati.com
So they should start now, with CLR you can get much more far away...
Shimmy
+1  A: 

Using the right tool for the job.

I've got nothing against an object database, but SQL is very, very good at expressing queries in a functional manner which allow them to optomised and parallelised. The data needs to be regular to do this effectively which is why we have SQL Server.

Effectively I see SQL as the right tool for the job of storing and searching phenomonally large data sets in an efficient way. You combine this with good tools and mappings and you should theoretically end up with the best of both worlds.

PS: I do see a convergence to what you are describing, SQL 2005 already natively supports .Net data types and CLR procedures, so if this is embraced in the future we could have object databases leveraging the awesome base of SQL server.

Spence
+5  A: 

Let me guess, you are a developer :)

You are only seeing the 'SQL' tip-of-iceberg of a database. But the language and programability part is only the front gate of the database. What really defines a high-end RDBMS are the 'ities':

  • high availability
  • disaster recoverability
  • scalability

The database better have a story for these or it cannot compete in the 'mission-critical' market where SQL Server is targeted primarily to compete (ie. the MSSQL-DB2-Oracle triumvirate market). BTW, you did mark the question as sql-server, so I can answer specific to this as opposed to tacking the more general 'RDBMS vs. OODB' path.

Now you take these high-end requirements out of the equation, then you can do a quick search and find a myriad projects that lay some claim to the 'future of databases' chart.

That does not mean that things are not moving into that direction. The ice was broken with SQL 2005 and the CLR integration. In SQL 2005 the CLR was a feature available for new applications to use, but no internals were based on it. Obviously, nobody would want a mission-critical platform to rely on such a new an untested functionality. In SQL 2008 things moved a little further, some system data types were shipped based on CLR: the geography and geospatial datatypes.

On the other hand the work Anders Hejlsberg did with C# 3.0 was truly revolutionary, so many elements of the language put together so coherently to offer a new abstraction, LINQ. Will the changes in paradigm occurring in the programming language percolate further down the stack to the database? I'm pretty sure. Will it take time? My bet is at least 2 releases.

Remus Rusanu