<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>LINQ: Enabling or Entangling?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx</link><description>There’s been a lot of positive press for LINQ, such as the article about LINQ by Mike Otey at http://www.sqlmag.com/Article/ArticleID/48759/sql_server_48759.html . You can also find lots of glowing reviews and info about LINQ by Troy Magennis at http://blog.aspiring-technology.com/</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>LINQ to SQL: Does it have much of a future?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx#10737</link><pubDate>Tue, 23 Dec 2008 22:33:35 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10737</guid><dc:creator>The Bit Bucket (Greg Low)</dc:creator><description>&lt;p&gt;Kevin Kline recently posted , wondering about the directions for LINQ. When people refer to LINQ, they're&lt;/p&gt;
</description></item><item><title>re: LINQ: Enabling or Entangling?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx#10741</link><pubDate>Wed, 24 Dec 2008 01:45:25 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10741</guid><dc:creator>Armando Prato</dc:creator><description>&lt;p&gt;I think the fundamental problem is that MS is trying too hard to make database programming &amp;quot;easy&amp;quot;. Like you said, there's no substitute for proper design. In the rush to build a pretty application, the proper foundation is rarely laid down. &amp;nbsp;The database is more than a place to just stick data. &amp;nbsp;The database is your foundation and its data is the most critical component of your company.&lt;/p&gt;
</description></item><item><title>re: LINQ: Enabling or Entangling?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx#10752</link><pubDate>Wed, 24 Dec 2008 15:25:03 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10752</guid><dc:creator>aspiringgeek</dc:creator><description>&lt;p&gt;I missed Andy's excellent post until you pointed me to it:&lt;/p&gt;
&lt;p&gt; &amp;nbsp;&lt;a rel="nofollow" target="_new" href="http://sqlblog.com/blogs/andrew_kelly/archive/2007/09/06/linq-to-the-rescue.aspx"&gt;http://sqlblog.com/blogs/andrew_kelly/archive/2007/09/06/linq-to-the-rescue.aspx&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;You're both right on. &amp;nbsp;Making things too easy isn't a good thing. &amp;nbsp;Nicely done.&lt;/p&gt;
</description></item><item><title>re: LINQ: Enabling or Entangling?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx#10778</link><pubDate>Sun, 28 Dec 2008 19:27:59 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10778</guid><dc:creator>Steve Dassin</dc:creator><description>&lt;p&gt;From:&lt;/p&gt;
&lt;p&gt;CS Techcast 55: Database Trends&lt;/p&gt;
&lt;p&gt;&lt;a rel="nofollow" target="_new" href="http://www.consortioservices.com/Blog/2008/12/23/CSTechcast55DatabaseTrends.aspx"&gt;http://www.consortioservices.com/Blog/2008/12/23/CSTechcast55DatabaseTrends.aspx&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Billy Bosworth, SQL Server VP &amp;amp; GM of Quest Software. &lt;/p&gt;
&lt;p&gt;&amp;quot;Lets look at the MS vision of the future when you talk about their data access layers. They're really 'discouraging' any continued paradigm of using sequel(sql) inside an application. They want you to use Linq, they want you to use all their object relational&lt;/p&gt;
&lt;p&gt;mapping layers and they want you to be able to write in terms of object classes and not necessarily in thinking in terms of rows and columns and tables.&amp;quot;&lt;/p&gt;
&lt;p&gt;This is an accurate assessment of where sql is in the mix of application development. It's been subtracted and as far as MS is concerned less is more. There is no longer any motivation from MS for developers to model business problems relationally. This is one of the greatest snuff jobs in IT history. MS is redefining the meaning of sql, S(queezing)Q(ueries)L(ifeless). And what has been the response of the sql community to this historic vote of no confidence? From the evidence, far too little and probably far too late. If the MS sql community wants to make itself relevant to MS application development they better find some strategists and &lt;/p&gt;
&lt;p&gt;politicans among the geeks:)&lt;/p&gt;
&lt;p&gt;&amp;gt;Making things too easy isn't a good thing. &lt;/p&gt;
&lt;p&gt;Besides being a shallow and trite summation of what MS is trying to do, has anyone considered the flip side of the coin? That sql has forever had the market cornered on obfuscation and counterintuitiveness as far as developers are concerned? Developers would perceive anything compared to sql as 'easier':)&lt;/p&gt;
</description></item><item><title>re: LINQ: Enabling or Entangling?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx#10780</link><pubDate>Mon, 29 Dec 2008 00:55:31 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10780</guid><dc:creator>Armando Prato</dc:creator><description>&lt;p&gt;The SQL language has been around for years in albeit various flavors. Now compare this to the application language &amp;quot;flavors of the month&amp;quot; that have come (and gone in some cases) such as Visual BASIC, C, C++, Visual C++, Powerbuilder, Java, Visual J++ (remember that one?), and now the .Net languages. &amp;nbsp;If anything, the SQL language has been relatively stable when compared to application programming languages despite its &amp;quot;counterintuitiveness&amp;quot;. &amp;nbsp; &lt;/p&gt;
&lt;p&gt;As a database professional, I have seen some pretty applications with absolutely HORRENDOUS data models which have led to a myriad db issues (i.e. excessive blocking, deadlocks, etc). &amp;nbsp;Most times it's not the database per se that is at fault. It's the lack of design which was not thought out or neglected altogether in the rush to build a functioning application. &amp;nbsp;LINQ, in my opinion, does not help this situation at all.&lt;/p&gt;
&lt;p&gt;If one is going to take the time to learn the next application language &amp;quot;flavor of the month&amp;quot;, why not take some time to learn and understand what makes for a good database design? &amp;nbsp;I'll never understand why a lot of developers consider the database as a &amp;quot;necessary evil&amp;quot; as opposed to what it truly is: &amp;nbsp;A partner in the building of a scalable, robust application.&lt;/p&gt;
</description></item><item><title>re: LINQ: Enabling or Entangling?</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2008/12/23/linq-enabling-or-entangling.aspx#10803</link><pubDate>Tue, 30 Dec 2008 04:47:41 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:10803</guid><dc:creator>Steve Mitcham</dc:creator><description>&lt;p&gt;Don't make the mistake of thinking that LINQ is limited to Entity Frameworks, or LINQ to SQL. &amp;nbsp;I've been using LINQ to objects and custom providers for LINQ very successfully in my projects that have no DAL and it is simplifying and clarifying our codebase by leaps and bounds.&lt;/p&gt;
</description></item></channel></rss>