Weird design decision in LinQ To SQL

[teddysnips]

I'm taking a look at LinQ to SQL and I'm mystified by a design
decision taken by the language design mavens.

Take this simple snipple:

var q =
from c in db.Customers
where c.City == "London"
select c.CompanyName;

Why is this not in the order that standard SQL takes - e.g.

var q =
select c.CompanyName
from c in db.Customers
where c.City == "London";

It Just Doesn't Make Sense.

Edward

 

[Marc Gravell]

Actually, getting the "from" first makes a lot MORE sense IMO, and you
can see how this allows everything that follows to make better use of
intellisense etc; how can it tell you what you can select if you
haven't told it what you are talking about first?

 

[Jon Skeet [C# MVP]]

Actually, getting the "from" first makes a lot MORE sense IMO, and you
can see how this allows everything that follows to make better use of
intellisense etc; how can it tell you what you can select if you
haven't told it what you are talking about first?

Exactly. If you draw a diagram of what sequence is represented at
every stage, it makes perfect sense with LINQ queries - it goes from
top to bottom.

Not that I've been drawing that kind of diagram myself, of course

Jon

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Have you stopped to think that maybe the way you always did it is not the
correct one?

 

[Nicholas Paldino [.NET/C# MVP]]

The opening chapter of "Inside SQL Server 2005: T-SQL Querying" actually
takes a SQL statement with joins, where, and an order clause and breaks down
exactly how SQL Server (and most RDBMSs) would handle it. The data source
(from, and joins) are always processed first, with the select processed
last.

Anders has even stated that this is more natural to him, given how SQL
queries are processed.

 

[Jon Skeet [C# MVP]]

The opening chapter of "Inside SQL Server 2005: T-SQL Querying" actually
takes a SQL statement with joins, where, and an order clause and breaks down
exactly how SQL Server (and most RDBMSs) would handle it. The data source
(from, and joins) are always processed first, with the select processed
last.

Anders has even stated that this is more natural to him, given how SQL
queries are processed.

Exactly - without the context of the data source, the "select" doesn't
make any sense at all. The engine can't really do anything with it
until it's looked at the rest of the query.

Jon

 

[Cor Ligthert[MVP]]

Teddy,

For me is SQL always been a very difficult dialect to understand. (I was
already a devellopper before the time it was created, therefore I learned it
never on school).

From the start all languages were describing what to take and then what to
do with it. And that always from the top to the bottom.

In the seventies there came as SQL meant as an enduser scripting language to
be in Plain English (whatever that distincts that "Plain" from real English
are in my idea words as Drop, Truncate and things as that). For the latter,
I am not an Englishman and as somebody here from the area of the real Oxford
tells me that it is plain English, then I believe him of course.

However, for me (as an old developper from before the start of SQL) has SQL
forever been the most unlogical developper language that was ever designed.

Just my 2 cents.

Cor

 

[Arto Viitanen]

(e-mail address removed) kirjoitti:

I'm taking a look at LinQ to SQL and I'm mystified by a design
decision taken by the language design mavens.

Take this simple snipple:

var q =
from c in db.Customers
where c.City == "London"
select c.CompanyName;

Why is this not in the order that standard SQL takes - e.g.

var q =
select c.CompanyName
from c in db.Customers
where c.City == "London";

Well SQL is based (mainly) or relational algebra, and in relational
algebra you would tell this

Project(CompanyName,
Restrict(City='London',
Customers))

Which is a little bit closer to the way you say in SQL. So yes, SQL
(almost) makes sence.