Is this end of T SQL / SQL ?

With LINQ becoming the language for developement in SQL Server 2008 ,

is Microsoft going to gradually come out of SQL .

Any enhancements to T-SQL in Katami ?

Thanks

Perhaps I'm being too naive, but I just can't imagine that they'd phase SQL/T-SQL out of a product named "SQL Server". :-)
|||

LINQ is not a replacement of T-SQL as such imho.

Some improvements in T-SQL are the MERGE statement, OVER() PARTITION BY for aggregate functions, multiple value inserts ...

LINQ may replace T-SQL on the application tier but I don't think T-SQL will ever dissapear as a whole ;-)

|||There are and will be mutliple additions to TSQL, but in terms of LINQ it won′t replace TSQL as e.g. the provider for SQL Server in LINQ to SQL uses TSQL under the covers, it is the native conversation language for this tier with SQL Server.

Jens K. Suessmeyer.

http://www.sqlserver2008.de
|||I actually see LINQ as a new opportunity of getting more performance tuning consulting, and thus I wish it welcome with all my heart I've never seen any "abstraction" of SQL that actually works well, and are able to create well optimized code. What bothers me is the idea of even more software developers with little or no skills in databases.|||

Hehe, right on ;-)

But lets give Microsoft the benefit of the doubt. There is a possibility to work with stored procedures from LINQ too.

|||Sure, it will be possible to create use procs with LINQ. But what about today? Developers don't know how to build procs today, and I see it even less likely that they will when LINQ is out |||

SQL Server continues to invest in Transact-SQL as a server-side programming language, with full support for the language on the client-side. There are a number of enhancements to T-SQL in SQL Server 2008, including the new date and time data types and related built-in functions, table-valued parameters, the MERGE statement, grouping sets, INSERT with nested DML, and many more. Most of the above enhancements are available in the SQL Server 2008 June CTP and are documented in SQL Server 2008 June CTP Books Online. Keep a lookout for more T-SQL enhancements in future CTPs.

|||

LINQ is the result of a longstanding (read: decades) observation that there is a huge impedence mismatch between the primary language (read: C#, etc.) and the Data Sublanguage (read: SQL these days) that makes it very difficult for programmers to access databases. One has to go back to the Codasyl days (early to mid 1970s), where the data sublanguage was actually defined by the same people who defined Cobol and some Cobol compilers had built in support for it, to find a point in time where this was not a major issue. Database folks have tried to address this in limited ways in the past. For example, embedding SQL in other languages via subcompilers. SQL is particularly bad for that because it is a non-procedural language. DEC Rdb had something variously called RDO or RDML (referring to the utilities rather than the unnamed language...internally we called it RDML most of the time) that fit into 3GLs better, but it lost out to SQL. So the purpose of LINQ is to give C# (and other) programmers a way to access data that is natural to THEM as opposed to making them learn a rather foreign data sublanguage and try to integrate the two. Only time will tell how well it succeeds.

LINQ (and some other things in SQL Server 2008) reflect the patterns that developers often use to write applications. For example, they tend to deal with entities rather than tables. Oh, there is code that deals with tables but what it does is construct entities (e.g., orders versus separate order headers and line items) for use in other parts of the application. And if you look at a lot of that code, it constructs the most brain dead bad SQL queries imaginable. So why not materialize and manipulate the entities directly? Does that mean no one will ever want to use SQL's ability to transform one or more tables into a new table (which is what every SQL query does)? Of course not. It means for some set of scenarios there is an access pattern that is better tied to how application programers work.

SQL will be around "forever" both because it is the universal language for talking to databases and because the DBA community (and other serious database programmers) will continue to embrace it no matter what other communities prefer. LINQ will hopefully be a big success in bringing more developers into the data fold and lead to the creation of more innovative and higher quality applications. But any specific outcome in 5 years, 10 years, 20 years, etc. is impossible to predict and no one will even attempt it. It's just not productive.

Hal

|||

In addition to what Hal and Sara already mentioned:

LINQ per se is the ability to provide a declarative programming style in the context of a procedural programming environment. It's family spans a couple of specific extensions for non-CLR data models, among then LINQ on XML for operating on in-memory XML documents, LINQ on SQL that provides an easier integration of mid-tier data programming to SQL, and LINQ on Entities that provides that over the new EDM model.

Today, LINQ on SQL is a mid-tier programming model that can run inside SQL CLR functions but is not meant to be replacing T-SQL. Tomorrow, our thinking is going more towards enabling users to chose the programming environment that they feel comfortable in and enable them to be productive quickly, effectively and efficently. This means T-SQL as well as potentially other programming paradigms (and, no I don't see PL/SQL anytime soon ).

Note also that there is a difference between SQL the declarative query language and T-SQL the procedural extensions. SQL as the query language is an ISO/ANSI standard and as such, it is unlikely to disappear.

Best regards

Michael