Why LINQ is better than SQL (Part 1?)

To be very honest, LINQ warms the cockles of my heart. The mere fact that I can write a compiler-checked query in C# that references my C# entity class and that query, through some magic incantations, gets executed as a SQL statement against my database...it makes me happy.

But maybe you're more pragmatic than I am. Maybe you think all this LINQ hoo-ha is pure sophistry. Take my word for it, I could go on and on about the wonders of LINQ, but then "I don't have time for this" do I?..Well, maybe one tiny example (since you asked so nicely):

    var r = (
        from e in context.Employee
        where e.Manager.Contact.LastName == "Word"
        select new { e.Contact.FirstName, e.Contact.LastName });

What's the big deal? This query traverses four logical tables. I didn't have to specify how those tables get joined together. Maybe this is kind of obvious, but it surprises me that standard SQL does not have a similar capability. Databases have these things called foreign keys that formalize the relationship between tables. That being the case, why do I have to spell out the relationship between every table in every query.

Don't get me wrong, I love SQL joins. Like the other day, when I needed to identify value gaps in a set of rows. Once upon a time, I probably would've resorted to some process involving cursors, but a simple self-join does the trick. The problem is that the chance to do something "clever" with a join doesn't come up very often. Most of the time (for me, at least), a join is identical to the relationship defined by a foreign key.