有人想到“CLR Server”而不是“SQL Server”吗？

Question

我想了很多次，现在我们有 Linq 和其他特定于 CLR 语言的内置搜索、排序和其他对表、集合和对象的功能，为什么不拥有“SQL Server”，或者更确切地说它是“ CLR 服务器（不仅是 OOP 服务器，还有 CLR 3.5），它将是一个 CLR（或 COM）DLL，它公开数据，允许用户直接在它上面进行 linqing；这将节省大量的现金痛苦，用两种不同的语言开发的时间等等。 我不是说（上帝保佑）抛弃 SQL，它只是在我脑海中闪过很多次，我想让我们听听社区怎么说。

当然，这个想法并不是全新的，FoxPro 中有这样的（与我的想法不同）数据库。 但我说的是一个纯 CLR .NET 3.5+ DB，它允许外部访问 DLL，甚至不应该生成 SQL 查询，整个系统应该以不同的方式工作。

插入更新和删除应该有额外的 Linq 关键字，但它们都应该是“Linq 样式”。

我 100% 肯定微软之前一直在考虑这个问题，也许他们有性能考虑和更多的 IDK，让我听听你的意见，我个人认为今天使用 .NET 3.5-4.0 如果我们会有集合处理，扩展服务器中的方法等将所有数据视为对象，这可能真的很酷（关于编码，再一次，不知道性能如何）。

你说什么？ 希望这个问题问对了地方，请提前接受我的道歉，如果不属于这里，请评论，我会删除。

对不起这个糟糕的例子，但请理解：

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

然后我们可以导入命名空间并使用内联的 ObjectContext。 请不要说“坏代码”，因为它是坏代码，我只是在 Stackoverflow 所见即所得编辑器中写了一个糟糕的伪示例，只是为了让你明白我的意思。

Answer 1

让我猜猜，你是开发者:)

您只看到了数据库的“SQL”冰山一角。但语言和可编程性部分只是数据库的前门。真正定义高端 RDBMS 的是“实体”：

• 高可用性
• 灾难恢复性
• 可扩展性

数据库最好有这些故事，否则它无法在 SQL Server 主要竞争的“关键任务”市场（即 MSSQL-DB2-Oracle 三巨头市场）中竞争。顺便说一句，您确实将问题标记为 sql-server，因此我可以针对此问题进行具体回答，而不是采用更通用的“RDBMS 与 OODB”路径。

现在您将这些高端要求排除在外，然后您可以快速搜索 并找到无数声称“数据库的未来”图表的项目。

这并不意味着事情没有朝着那个方向发展。 SQL 2005 和 CLR 集成打破了僵局。在 SQL 2005 中，CLR 是一项可供新应用程序使用的功能，但没有任何内部结构基于它。显然，没有人会希望关键任务平台依赖这种未经测试的新功能。在 SQL 2008 中，事情更进一步，一些系统数据类型基于 CLR：地理和地理空间数据类型。

另一方面，Anders Hejlsberg 对 C# 3.0 所做的工作确实具有革命性，该语言的许多元素如此连贯地组合在一起以提供新的抽象，LINQ。编程语言中发生的范式变化会进一步向下渗透到数据库吗？我确信。需要时间吗？我敢打赌至少有 2 个版本。

Answer 2

您正在描述一个对象数据库。这是一个：

db4o C# 数据库

• 原生于 .NET 2 和 3.5（包括 紧凑框架）
• 100% 面向对象的数据库，否 对象关系映射
• 专为嵌入式使用而设计 零管理环境
• 在 GPL 下开源且免费

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

Answer 3

会很整洁，但是在对象模型和数据存储之间有一个额外的抽象层可以进行大量优化。当您使用如果删除 SQL 层就必须重新发明的查询来访问 SQL Server 时，会在 SQL Server 内部发生很多很酷的事情。我相信有一天它会发生，但不确定它是否有足够的好处来证明今天这样的事情是合理的...... JMHO......

Answer 4

为工作使用正确的工具。

我对对象数据库一无所知，但是 SQL 非常非常擅长以函数式方式表达查询，从而允许它们进行优化和并行化。数据需要有规律才能有效地做到这一点，这就是我们拥有 SQL Server 的原因。

实际上，我认为 SQL 是一种以有效方式存储和搜索超大型数据集的正确工具。您将其与良好的工具和映射结合起来，理论上您应该得到两全其美的结果。

PS：我确实看到了与您所描述的内容的融合，SQL 2005 已经原生支持 .Net 数据类型和 CLR 过程，因此如果将来采用这种方式，我们可以拥有利用 SQL Server 强大基础的对象数据库。

Answer 5

LINQ to SQL 是 .NET Framework 中附带的 O/RM（对象关系映射）实现，它允许您使用 .NET 类对关系数据库进行建模。然后，您可以使用 LINQ 查询数据库，并从中更新/插入/删除数据。

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