Skip to main content

Linq, SQL, CAML

So I went to a presentation about Linq yesterday. The presentation was given by Scott Allen. Before I get into my impressions of the content, let me say a few things about the packaging. You know how they say first impressions count? Well Scott Allen either didn't know that or he just plain ignored it. I wasn't impressed with the dude's appearance. But, before you crush me with accusations of superficiality, I have to say 5 minutes into the talk I was already impressed with his content. His tone was just right and the approach he took to explaining Linq (and even the use of "var" which I, hitherto, thoroughly despised) was excellent.

That said, I am sold on Linq-to-everything but sql. Some of the language enhancements that were made to support Linq are things I have always wanted to do. For example, you have a list with several items and you want to find items that match a criteria. How do you do it? You write a loop that has a lot of what Scott called "ceremony" i.e. fluff:

List matches = new List();
foreach (MyType x in myTypes)
{
if (MatchesCriteria(x))
{
matches.Add(x);
}
}

With C# 3.0, you just write
var matches = from t in myTypes
where t.StartsWith("svchost")
select t;

Imagine being able to query an xml document, a web service and a collection of objects with the same syntax.

So we are all in agreement that Linq is great for querying objects. However, where it breaks down for me is when you start using Linq to query modern day databases. I have a few problems with LinqToSQL
  • Microsoft's implementation of LinqToSQL (and I suspect all other implementations) uses queries generated on the fly. Sure SQL Server will optimize and cache queries for you but how do test the generated queries? How do you know the queries being generated by Microsoft's LinqtoSQL provider generates sound queries when it has no prior knowledge of your database?
  • When you use LinqToSQL, you give up all the power of SQL for the simplicity of Linq's syntax. For trivial applications that might be a good trade off (after all who wants to bother with stored procedures, views and functions in a trivial app). But for non-trivial apps, I think you need the flexibility and power of SQL with a C#
  • Ignoring the efficiency issue, when you start mixing queries with C# code, isn't that just a recipe for maintenance nightmare? Imagine how much harder it'll be when renaming a table; adding new columns, dropping existing columns, modifying existings columns...if you've got C# code directly accessing those objects.
  • What's so wrong with plain old SQL? Attempts to replace SQL with a 4th generation language-based query language will almost always fail. Why? For one 4th generation languages are geared towards you (the developer) coming up with the algorithm to retrieve data. Whereas, SQL is all about tell the RDBMS what to get and it figures out the best way to get it. When you start writing queries in C#, C++, Java, XML...well to me it looks like you are trying to do too much. And you just might end up with CAML, which is a truly awful query language native to SharePoint.
I get why Microsoft might have felt the need to introduce LinqToSQL for completeness sake. After all, you can't talk query with talking SQL. But I fail to see how one could use LinqToSQL in non-trivial applications.

Comments

  1. While this tends to take away from a DBA's job, which I despise, some would argue Microsoft always has to have a response to J2EE. Hibernate, and JPAs have been a sore topic in some development circles for a while, but to others they are a God sent response to the need to do any true RDBMS designing leaving all the work to a 3rd party layer.

    Well Microsoft came up with Linq to respond to JPA, and while I can't feel your pain just yet since I haven't dealt with whatever nightmare of as schema Linq would cause. I can only imagine it is typical. Which would be under optimized queries and the other myriad of issues that go along with Model managing tools.

    ReplyDelete

Post a Comment

Popular posts from this blog

InfoPath & SharePoint (Part 1)

A departure from sports and politics. This one is about technology.

InfoPath sucks and SharePoint is the most expensive piece of crap ever. InfoPath, as a development environment, has absolutely no redeeming value. It's worthless and if your boss ever thinks of using it, you have three options:

convince him not to (not easy once he's been brainwashed by the Microsoft marketing presentations)use one of Al Gore's lockboxes to store away your sanity 'cos you'll lose it. Also, pad your estimates very generously. You'll need every bit of time you can get.
quit immediately while you still have your sanityFirst, InfoPath:

To me InfoPath is like programming in assembly language. Sure it makes it easy (too easy in fact) to bind data to controls. But it doesn't provide you with easy access to your controls. Why is this important? Say you want to disable a button:

in most technology: buttonA.enabled = false (or something similar).

In InfoPath, you simply can't do this.…

Does InfoPath (still) suck?

A couple of years ago, I wrote a blog post titled "InfoPath & SharePoint (Part 1)". Back then I had just started working on a project using InfoPath 2007. So, expectedly, the post wasn't very complimentary to InfoPath (or SharePoint). In fact, I said:
InfoPath sucks and SharePoint is the most expensive piece of crap ever. InfoPath, as a development environment, has absolutely no redeeming value. It's worthless.... (more)Since then my opinion of InfoPath has changed slightly. It still suffers from all the flaws I pointed out in that post. However, I think when used right, InfoPath can be an OK tool. I think it's well suited for designing one off forms and not for anything that requires complex logic or multiple iterations (like most software development requires). Alas, most CTOs fall in love with its point & click simplicity and integration with SharePoint that they try to use it to replace more developed technologies like ASP.NET. What do you get? A horri…

Technical Certifications are worthless

Technical certifications, especially in the IT field, are totally worthless. Why? All a technical certification prove is that you were able to buy a couple of exam prep books, cram them in a week or two and take an exam. My monkey (if I had one) could do that. I can't tell you how many times I have interviewed certification-carrying candidates for open positions at my company only to find them severely lacking in thorough understanding of computer science. I don't care that you have an MSCD or MCP or whatever it's called these days if you don't know foundational concepts in computer science and database design.
For example, I don't want someone who just knows that you store things in a hashtable using keys. I need you to know why a hashtable is better than an array in some cases. I need you to know when an interface is better than an abstract class; when to use recursion; the different kinds of joins and when to use each one; I need you to understand how crucial sou…