Est-ce quelqu'un pense « CLR serveur » au lieu « SQL Server »?

StackOverflow https://stackoverflow.com/questions/1175517

Question

Je pensais à plusieurs reprises, maintenant des jours que nous avons Linq et autres recherche, de tri et intégré spécifique à la langue CLR autres capacités sur les tables, les collections et objets, pourquoi pas le « SQL Server » ou appeler plutôt ' CLR Server »(non seulement POO Server, mais CLR 3.5 ) qui sera un CLR (ou COM) DLL qui expose les données permettant aux utilisateurs linqing droit dessus; cela permettra d'économiser beaucoup de douleur cuncurrency, le temps de se développer dans deux langues différentes et ainsi de suite. Je ne dis pas (à Dieu ne plaise) jeter SQL, il traverse tout mon esprit à plusieurs reprises, je pensais Écoutons ce que la communauté dit au sujet.

Cette idée est pas tout à fait nouveau bien sûr, il est tel (différent de mon idée tho) un DB dans FoxPro. Mais je parle d'un 3.5+ .NET pur CLR DB qui permettra l'accès à la DLL externe, ne devrait pas même générer des requêtes SQL, le système devrait fonctionner différemment.

Il devrait y avoir des mots-clés Linq supplémentaires pour la mise à jour d'insertion et de suppression, mais ils doivent tous être « style Linq ».

Je suis 100% sûr que Microsoft a pensé à cela avant peut-être qu'ils avaient des considérations de performance et plus IDK, laissez-moi entendre vos opinions, je pense personnellement que aujourd'hui avec 3,5-4,0 .NET si nous aurons la gestion de la collecte, Extension méthodes, etc. dans le serveur de traitement de toutes les données comme objet, il pourrait être vraiment cool (en ce qui concerne le codage, encore une fois, Donno ce que sur la performance).

Whatcha Say? J'espère que cette question a été posée au bon endroit, s'il vous plaît accepter mes excuses à l'avance, si elle ne fait pas partie ici, s'il vous plaît commentaire et je vais le supprimer.

Désolé pour cet exemple pauvre, mais s'il vous plaît obtenir l'idée: 

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

Nous pourrions alors importer les espaces de noms et d'utiliser la ligne ObjectContext. S'il vous plaît ne pas dire « mauvais code » cuz il est mauvais code, je n'écrit un mauvais exemple pseude droit dans l'éditeur WYSIWYG Stackoverflow pour vous de voir ce que je veux dire.

Était-ce utile?

La solution

Vous décrivez une base de données d'objets. Voici un:

db4o C # Base de données

  • Natif de .NET 2 et 3.5 (y compris le Compact Framework)
  • 100% base de données orientée objet, non mapping objet-relationnel
  • Conçu pour une utilisation embarquée dans environnements zéro-admin
  • open source et libre sous licence GPL

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

Autres conseils

Laisse-moi deviner, vous êtes un développeur:)

Vous ne voyez la pointe de iceberg « SQL » d'une base de données. Mais la partie de la langue et est seulement la Possibilité de programmation porte d'entrée de la base de données. Ce qui définit vraiment un SGBDR haut de gamme sont les « ITIES »:

  • haute disponibilité
  • recouvrabilité des catastrophes
  • évolutivité

La meilleure base de données ont une histoire pour ceux-ci ou il ne peut rivaliser sur le marché de « mission critique » où SQL Server est destiné principalement à la concurrence (ie. Le marché MSSQL DB2 Oracle triumvirat). BTW, vous avez marquer la question sql-server, donc je peux répondre précisément à cette opposition à la clouant « SGBDR contre OODB » plus général chemin.

Maintenant, vous prenez ces exigences haut de gamme de l'équation, alors vous pouvez faire une recherche rapide et trouver une myriade de projets qui se trouvaient certains prétendent «l'avenir des bases de données de la carte.

Cela ne signifie pas que les choses ne bougent pas dans cette direction. La glace a été brisée avec SQL 2005 et l'intégration de CLR. Dans SQL 2005, le CLR est une fonctionnalité disponible pour les nouvelles applications à utiliser, mais pas internes étaient fondées sur elle. De toute évidence, personne ne voudrait une plate-forme de mission critique de compter sur une telle nouvelle une fonctionnalité non testé. Dans SQL 2008 les choses ont évolué un peu plus loin, certains types de données du système ont été expédiés en fonction de CLR: la géographie et les types de données géospatiales.

D'autre part, le travail Anders Hejlsberg fait avec C # 3.0 était vraiment révolutionnaire, tant d'éléments du langage mis ensemble de manière cohérente à offrir une nouvelle abstraction, LINQ. Est-ce que les changements de paradigme qui se produisent dans le langage de programmation percoler plus bas de la pile à la base de données? Je suis pratiquement sure. Sera-t-prendre le temps? Mon pari est d'au moins 2 versions.

serait bien, mais ayant une couche d'abstraction supplémentaire entre le modèle d'objet et la banque de données permet beaucoup d'optimisation. Il y a beaucoup de trucs cool passe à l'intérieur SQL Server lorsque vous frapper avec une requête qui devrait être réinventé si la suppression de la couche SQL. Je suis sûr qu'un jour il va se passer, mais pas sûr qu'il y ait assez d'avantages avec elle pour justifier quelque chose comme ça aujourd'hui ... JMHO ...

Utilisation de l'outil pour le travail.

Je n'ai rien contre une base de données d'objets, mais SQL est très, très bon à exprimer des requêtes de manière fonctionnelle qui leur permettent de optomised et parallélisés. Les données doivent être régulières pour le faire efficacement, ce qui est la raison pour laquelle nous avons SQL Server.

En effet, je vois SQL comme outil pour le travail de stockage et de recherche des ensembles de données phenomonally grandes d'une manière efficace. Vous combinez cela avec de bons outils et applications et vous devriez finir théoriquement avec le meilleur des deux mondes.

PS: Je ne vois une convergence à ce que vous décrivez, SQL 2005 prend déjà en charge nativement les types de données .Net et procédures CLR, donc si cela est embrassé dans l'avenir nous pourrions avoir des bases de données d'objets tirant parti de la base impressionnante de serveur SQL.

LINQ to SQL est un O / RM (mapping objet relationnel) la mise en œuvre que les navires dans le .NET Framework, et qui vous permet de modéliser une base de données relationnelle en utilisant des classes .NET. Vous pouvez ensuite interroger la base de données en utilisant LINQ, ainsi que la mise à jour / insertion / suppression des données de celui-ci.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top