Why can't recursive queries contain...?
in [Programming SQL]
|
Prev: Sql Server on VMWare
Next: AdventureWorks database
From: Michael C on 7 Dec 2009 18:55 "Michael Coles" <michaelcoAToptonlineDOTnet> wrote in message > Unfortunately the ability to return a .NET DataTable in .NET code != SQL > Server TVP Support Depends how you look at it. I only use linq to objects and call the database via ado.net so to me it means it does work. > At this point I have no definition for a "native linq database". It > sounds like a marketing slogan more than a real enterprise DBMS. That suprised me. I thought it was such an obvious idea that it was just a matter of time before it would be released. Why write a new sql style language if we don't have a database that uses it directly? > So far we've seen a wish list of DBMS and database language features, but > not a foundation for an enterprise DBMS. BTW, the MS push appears to be > to get people using EF instead of LINQ right now. Microsoft tend to market all their new features (of course) but many confuse this with microsoft recommending this as the best way to do things. Michael
From: Michael Coles on 7 Dec 2009 22:52 > Depends how you look at it. I only use linq to objects and call the > database via ado.net so to me it means it does work. I can see that possibly working; however, it does not equal SQL Server TVP support in LINQ. It's simply a workaround for the lack of support, and if you're dealing in disconnected datasets a potentially costly one. The fact that you don't even use SQL 2008 means you have no idea whether or not even this workaround will work. > That suprised me. I thought it was such an obvious idea that it was just a > matter of time before it would be released. Why write a new sql style > language if we don't have a database that uses it directly? Maybe because no one has defined it. The obvious ideas are often the trickiest to define, much less implement, because people tend to take a lot of things for granted. If it really is that obvious, take a shot at giving it a clear definition. > Microsoft tend to market all their new features (of course) but many > confuse this with microsoft recommending this as the best way to do > things. Actually LINQ and EF are both living in the OR/M space right now. Some might consider them competing products that offer similar functionality. If so the decision has to be made whether resources will be committed to one or the other, or if resources will be split to develop both. From what I've read it sounds like the decision was made to dedicate resources towards EF. -- Thanks Michael Coles SQL Server MVP Author, "Expert SQL Server 2008 Encryption" (http://www.apress.com/book/view/1430224649) ---------------- "Michael C" <mike(a)nospam.com> wrote in message news:uicMUj5dKHA.2184(a)TK2MSFTNGP04.phx.gbl... > "Michael Coles" <michaelcoAToptonlineDOTnet> wrote in message >> Unfortunately the ability to return a .NET DataTable in .NET code != SQL >> Server TVP Support > > Depends how you look at it. I only use linq to objects and call the > database via ado.net so to me it means it does work. > >> At this point I have no definition for a "native linq database". It >> sounds like a marketing slogan more than a real enterprise DBMS. > > That suprised me. I thought it was such an obvious idea that it was just a > matter of time before it would be released. Why write a new sql style > language if we don't have a database that uses it directly? > >> So far we've seen a wish list of DBMS and database language features, but >> not a foundation for an enterprise DBMS. BTW, the MS push appears to be >> to get people using EF instead of LINQ right now. > > Microsoft tend to market all their new features (of course) but many > confuse this with microsoft recommending this as the best way to do > things. > > Michael >
From: Michael Coles on 8 Dec 2009 10:49 "Michael C" <mike(a)nospam.com> wrote in message news:%23MMsQw7dKHA.1592(a)TK2MSFTNGP06.phx.gbl... > Again it depends on how you look at it. Certainly linq to objects does not > restrict you from using TVPs. And while your television probably doesn't provide any food digestion functionality, it certainly does not restrict you from digesting your food. Talking backwards you might be able to convince yourself, but it still makes no sense. LINQ to Objects does not support TVPs because they are a SQL Server construct. This was why I asked you previously if you actually knew what a TVP is. You're talking yourself into believing that an ADO.NET DataSet is the same thing as a TVP. The ADO.NET DataSet can be used to populate a TVP, but it is *not* a TVP; in much the same way an XML file can be used to populate a relational database, but an XML file is *not* a relational database.
From: Michael C on 8 Dec 2009 19:00 "Michael Coles" <michaelcoAToptonlineDOTnet> wrote in message > And while your television probably doesn't provide any food digestion > functionality, it certainly does not restrict you from digesting your > food. Talking backwards you might be able to convince yourself, but it > still makes no sense. LINQ to Objects does not support TVPs because they > are a SQL Server construct. This was why I asked you previously if you > actually knew what a TVP is. You're talking yourself into believing that > an ADO.NET DataSet is the same thing as a TVP. The ADO.NET DataSet can be > used to populate a TVP, but it is *not* a TVP; in much the same way an XML > file can be used to populate a relational database, but an XML file is > *not* a relational database. Again, it depends on how you look at it. Linq to objects can return the data needed for a TVP, basically it works with TVPs. Simple really. Your analogy is flawed as your television in no way has anything to do with digestion where linq marries up with ado.net and TVPs quite well. Michael
From: Michael Coles on 8 Dec 2009 19:34
"Michael C" <mike(a)nospam.com> wrote in message news:uM7HsKGeKHA.1592(a)TK2MSFTNGP06.phx.gbl... > Again, it depends on how you look at it. Linq to objects can return the > data needed for a TVP, basically it works with TVPs. Simple really. Your > analogy is flawed as your television in no way has anything to do with > digestion where linq marries up with ado.net and TVPs quite well. Since we're really stretching the definition of "support for TVPs", we can surely stretch the definition of "support for digestion" to include the Food Network. As you say, it depends on how you look at it, if you choose to look at it that way. :) The fact that the LINQ providers have no support for TVPs is not even a question. The fact that you can kludge around the lack of support by adding a layer of abstraction between SQL Server and LINQ doesn't change that fact. We could likewise say that JavaScript has no support for querying SQL Server directly; however, we can put a Web Service in between JavaScript and SQL Server to accept requests from JavaScript, connect to SQL Server, execute the query, and return the results to JavaScript in JSON format. This doesn't mean JavaScript now suddenly *poof* supports SQL Server querying -- what it means is we have added a layer of abstraction in between JavaScript and SQL Server that can communicate with both. You've proposed the same thing with ADO.NET, which doesn't suddenly mean that *wow* LINQ suddenly supports TVPs. -- Thanks Michael Coles SQL Server MVP Author, "Expert SQL Server 2008 Encryption" (http://www.apress.com/book/view/1430224649) ---------------- |