È stato chi pensa di "CLR Server' invece 'SQL Server'?

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

Domanda

Stavo pensando a quante volte, ormai giorni che abbiamo Linq e altri CLR specifico della lingua, built-in di ricerca, ordinamento e di altre capacità, oltre tabelle, collezioni e oggetti, perché non hanno "SQL Server" o meglio chiamarlo "CLR Server" (non solo OOP Server ma CLR 3.5) che sarà un CLR (o COM) DLL che espone i dati, consentendo agli utenti di linqing destro su di esso;questo vi farà risparmiare molto di cuncurrency dolore, il tempo di sviluppo in due lingue differenti e così via.Non sto dicendo che (dio non voglia buttare via SQL, e ' solo che attraversa la mia mente a molte volte, ho pensato che sentiamo ciò che la comunità ha da dire in merito.

Questa idea non è del tutto una novità, naturalmente, c'è (diverso della mia idea tho) un DB in FoxPro.Ma sto parlando di un puro CLR .NET 3.5+ DB che permetterà esterno accesso DLL, non dovrebbe anche generare Query SQL, tutto il sistema dovrebbe funzionare in modo diverso.

Non ci dovrebbero essere ulteriori Linq parole chiave per l'inserimento, aggiornamento e cancellazione, ma dovrebbero essere tutti 'Linq per stile'.

Io sono sicuro al 100% che Microsoft hanno pensato prima forse avevano considerazioni sulle prestazioni e più IDK, fatemi sentire le vostre opinioni, io personalmente penso che oggi con .NET 3.5-4.0, se avremo collezione di gestione, i metodi di Estensione etc.nel server di trattamento di tutti i dati come oggetto potrebbe essere davvero cool (per quanto riguarda la codifica, di nuovo, donno che cosa circa le prestazioni).

Whatcha dire?Spero che questa domanda è stato chiesto nel posto giusto, vi prego di accettare le mie scuse in anticipo, se non appartiene a qui, si prega di commento e io eliminarlo.

Mi dispiace per questa povera esempio, ma si prega di prendere l'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

Potremmo quindi importare il namespace e utilizzare l'ObjectContext inline.Si prega di non dire "codice non valido" perchè è di cattivo codice, ho solo scritto un povero pseude esempio a destra in Stackoverflow editor WYSIWYG solo per farvi vedere cosa intendo.

È stato utile?

Soluzione

Si sta descrivendo un database ad oggetti. Eccone uno:

db4o C # Database

  • Native a .NET 2 e 3.5 (tra cui Compact Framework)
  • 100% Object Oriented Database, no object-relational mapping
  • Progettato per l'uso incorporato in ambienti a zero-admin
  • open source e gratuito sotto licenza GPL

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

Altri suggerimenti

Fammi indovinare, sei uno sviluppatore:)

si sta vedendo solo il 'SQL' punta-di-iceberg di un database. Ma la parte lingua e programability è solo il cancello anteriore del database. Ciò che definisce veramente un high-end RDBMS sono i '' vità:

  • alta disponibilità
  • disastro recuperabilità
  • scalabilità

Il database meglio avere una storia per questi o non può competere sul mercato 'mission-critical', dove SQL Server si rivolge principalmente a competere (es. Il mercato triumvirato MSSQL-DB2-Oracle). BTW, hai contrassegnare la questione sql server, in modo da poter rispondere a questa specifica al contrario di virata del 'RDBMS vs OODB' più generale percorso.

Ora si prende questi requisiti di fascia alta fuori dall'equazione, allora si può fare una rapida ricerca e trovare una miriade di progetti che giacevano alcuni sostengono al 'futuro del database' tabella.

Ciò non significa che le cose non si stanno muovendo in quella direzione. Il ghiaccio era rotto con SQL 2005 e l'integrazione CLR. In SQL 2005, il CLR è una funzione disponibile per le nuove applicazioni da usare, ma non interni erano basate su di esso. Ovviamente, nessuno vorrebbe una piattaforma mission-critical fare affidamento su una nuova una funzionalità quali non testati. In SQL 2008 le cose spostati un po 'più, alcuni tipi di dati di sistema sono stati spediti in base CLR: la geografia e tipi di dati geospaziali.

D'altra parte il lavoro di Anders Hejlsberg ha fatto con C # 3.0 è stato veramente rivoluzionario, così tanti elementi del linguaggio messi insieme in modo coerente per offrire una nuova astrazione, LINQ. Saranno i cambiamenti di paradigma che si verificano nel linguaggio di programmazione percolato più in basso la pila al database? Sono abbastanza sicuro. Ci vorrà tempo? La mia scommessa è di almeno 2 uscite.

sarebbe stato facile, ma avere un livello di astrazione supplementare tra il modello a oggetti e l'archivio dati consente per un sacco di ottimizzazione. C'è un sacco di cose interessanti in corso all'interno di SQL Server quando lo ha colpito con una query che dovrebbe essere reinventato se la rimozione dello strato di SQL. Sono sicuro che un giorno accadrà, ma non so se c'è abbastanza benefici con essa per giustificare una cosa del genere oggi ... JMHO ...

Utilizzando lo strumento giusto per il lavoro.

Non ho niente contro un database ad oggetti, ma SQL è molto, molto bravo a esprimere le query in modo funzionale, che permettono loro di optomised e parallelised. I dati devono essere regolari per fare questo in modo efficace ed è per questo che abbiamo di SQL Server.

In effetti vedo SQL come lo strumento giusto per il lavoro di memorizzazione e la ricerca phenomonally grandi insiemi di dati in modo efficiente. Si combinano con buoni strumenti e le mappature e si dovrebbe teoricamente finire con il meglio dei due mondi.

PS: Vedo una convergenza a ciò che si sta descrivendo, SQL 2005 già supporta in modo nativo i tipi di dati .Net e delle procedure CLR, quindi se questo è abbracciato in futuro potremmo avere database degli oggetti sfruttando la base impressionante di server SQL.

LINQ to SQL è un O/RM (object relational mapping) di attuazione che navi .NET Framework, e che permette di modellare un database relazionale .NET classi.Si può quindi interrogare il database utilizzando LINQ, nonché di aggiornare/inserire/eliminare i dati da esso.

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top