June 5, 2007 at 10:17 am
An application developer approached me and asked what I thought about LINQ. Well, being the database guy, I wasn't sure how to respond. I did do some research and thought that I should post questions to the SQL Server community and get a feel for LINQ.
From my understanding, using LINQ will allow application developers to query data through XML, SQL, Stored Procedures, or for that matter many different types of data. I have always been a fan of using stored procedures due to performance, security, and the ability to capture SQL using Profiler for further performance analysis. It seems that LINQ will allow developers to write SQL in applications which makes me a little nervous. Why, because many Application developers are not adept to using SQL Syntax and do not understand perfomance considerations like "SELECT * FROM" or the use of many Temp Tables and Cursors.
For the SQL Server community, what are everyones thoughts on LINQ and how should we treat this new data access layer? Please feel free to provide long term direction, I am curious what others in the SQL Server community are saying about LINQ.
Thanks Greg
June 6, 2007 at 9:58 am
very carefully!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
June 6, 2007 at 10:05 am
Thanks for the reply. I was hoping that the SQL Server community would provide a little more thought around LINQ. I know its new, but I believe there are enough samples and some information on this new technology. It won't be long before VS.NET and SQL Server 2008 allow for these capabilities. But then again, is SQL Server 2008 really going to be delivered in 2008. Hmmm.
I watched the live webcast from TechEd on Monday June 4th, and SQL Server 2008 has a few nice features. Of course LINQ is only one feature (Whether it is nice or not.). I still don't think the majority of SQL Server users have even moved to SQL Server 2K5 yet, and a new release already.
Greg
June 6, 2007 at 10:39 am
Hi
I've not looked enough at LINQ yet (though will), so I'm definitely not claiming any expertise, but from what I have seen I would first say that LINQ itself is providing something that can look similar to SQL, but isn't actually SQL - it's an implementation neutral language (like SQL) rather than a DB layer. Hence DLINQ comes in and allows this to be translated to SQL on different platforms within your DB layer. I'm only saying that because the scope of exposing a database model is potentially a lot more than a DB layer.
It looks like it can be used in a fashion where the database is treated as an object database rather than a relational base, in which case I would expect bandwidth usage might go up a bit (more queries), though it may provide some caching mechanism to counter this.
I guess what will be interesting is how much control you have over the mapping to SQL, and whether you can develop a suitable OO to Relational DB Layer for your needs; hopefully also being able to hide your database model away so that it's not exposed wherever LINQ might be used!
Jon
June 6, 2007 at 8:23 pm
LINQ let you write queries in C#/VB.NET like SQL, I think it will reduce software development time because it will be easier to pass data from one SET to another SET. I also think mapping is not needed in most cases because you can just pass data from one layer to the other if you know data in native Data Structure. Check out the samples below Microsoft have introduced very interesting methods, I just hope there will be more functions than methods.
http://msdn2.microsoft.com/en-us/vcsharp/aa336746.aspx
Kind regards,
Gift Peddie
June 7, 2007 at 3:39 am
It's certainly an interesting situation - I agree that initial development time could be reduced quite considerably, but exposing a database's schema to the world (if that is the intent) rather than just a data access layer seems to carry risks since the more coupled it is to other areas, the less changeable it will likely be.
I think the ablility to phrase your question (what data you want) probably also has pros and cons - There's a long Anders.. interview where he describes asking for information you want at the top level of an app, and pulling the correct data (and only the required data) from different data sources (like forming pipelines to the data you need), which really does sounds great, and not having to write all manner of objects to handle this could save a lot of dev time, but on the flip side you could be relying on people *essentially* writing decent SQL (as mentioned in the original post), which might give a database caretaker a mild stroke? So the situation could be a bit of a trade between control of a system and ease of use?
Jon
June 7, 2007 at 6:11 am
I'm starting to slowly look into it. I'm about as convinced as I am about allowing CLR.... I.e. until there is a specific need for it, I am not allowing it on my servers.
I hope this becomes an ability that has to be enabled on the SQL side just like CLR though. I've worked too hard trying to get a handle on what is going on witht he SQL code on these servers to suddenly have to let it wide open again.
June 8, 2007 at 8:14 am
As a database developer, I'm not keen on the idea of allowing C# programmers to treat a production corporate database as though it was an Access Datastore. LINQ is flexible enough to allow you to use stored procedures, (see http://weblogs.asp.net/scottgu/archive/2006/06/18/DLINQ-with-Stored-Procedures.aspx) but the idea still makes me nervous. However, as a 'consumer' of other data-sources, I like the idea of being able to get data from a range of disparate data sources in a reasonably standard SQL-like syntax. That would suit me nicely. Steve McCabe at http://www.sqltac.com/ has done a lot of work in LINQ, and it is worth checking out what he's doing.
Best wishes,
Phil Factor
June 8, 2007 at 9:27 am
Thanks everyone for the responses. I do like the idea of LINQ being able to work with data easily. My concern is data access to the database. I have seen examples where DLINQ uses stored procedures and this suits me just fine. As the database developer and DBA, when I first saw this technology, it gave me a scare. I plan to continue to use stored procedures for data access and require that this method is the best approach for scalability and maintainability.
By the way, I live in Southern Oregon, and I just presented my first SQL Server Users Group. The first meeting was a success. We discussed SQL Server 2005 XML. Of course, I had to do some research while developing some of the code for the DML statements. I have done a lot of XML SQL Server querying in 2005, but haven't been exposed to the DML for SQL Server 2005 XML. I just wanted to share the success and look forward to the next meeting.
Thanks
Greg
June 11, 2007 at 6:04 am
There have been many tools such as LINQ in the past, that purport to make life easier for developers by avoiding the 'pain' of coding SQL. Most of these have been in the mainframe or *nix world. None of them has had any long term success - if a developer does not understand what data is needed to meet the business query, the syntax used to specify the query is irrelevant.
The big issue is that the developer has to format their query in LINQ. The LINQ interpreter then trys to translate this to SQL. Mostly it will work fine, but sometimes a valid LINQ query that should give a vaild SQL query will give a syntax error. (OK, I have never used LINQ, but as it is written by people it is likely to have a few bugs...) The developer typically then has to embellish the LINQ syntax to persuade the interpreter to produce valid SQL.
The syntax for LINQ does not include anything for SQL Hints, so if the LINQ query does not perform well, there is not much the DBA can do about it. Most queries do not need Hints, but the ones that do REALLY need it. I am just not convinced that specifying a query in LINQ will be any easier than specifying it in T-SQL, but I am convinced that it would make the support issues more complex.
If LINQ gets supported as a first-class language then the situation changes. If SQL can directly take LINQ syntax and produce a query plan, then the problems above would not arise. However, I have not heard of any plans to include this capability in SQL 2008.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply