Hi Chris and guys,
In doing my work for a LINQ 'Click Start' eVolume a couple of years back I found this :-
Check out the image attached as I no longer have the original text to copy and paste - it explains the reason for SELECT at the end and not the beginning.
LINQ
-
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
LINQ
Following on from what Otto said...
I don't know about X# but in C# you have the two different syntaxes available - query syntax
FROM Developer IN oList etc
and method syntax
oList.Where(lambda).OrderBy(lambda).ToList()
In method syntax the input into each method is the output of the previous method in the chain (so Where takes oList, OrderBy takes the result of the Where clause, etc).
Looked at that way it's all perfectly logical, aside from the reason Phil mentioned. It's only a problem if you approach it with the screwed up logic of SQL
Nick
I don't know about X# but in C# you have the two different syntaxes available - query syntax
FROM Developer IN oList etc
and method syntax
oList.Where(lambda).OrderBy(lambda).ToList()
In method syntax the input into each method is the output of the previous method in the chain (so Where takes oList, OrderBy takes the result of the Where clause, etc).
Looked at that way it's all perfectly logical, aside from the reason Phil mentioned. It's only a problem if you approach it with the screwed up logic of SQL
Nick
- lumberjack
- Posts: 727
- Joined: Fri Sep 25, 2015 3:11 pm
- Location: South Africa
LINQ
Phil and others,
I actually also think the Linq way is more logical compared to SQL.
My logic for SQL would actually be that the SELECT statement syntax is executed as a TOP to BOTTOM logic, e.g.:
FROM <table> [WHERE <tablewhere>][, <tablelist>]
WHERE <This will hold relationship constraints>
SELECT <column list>
Or from my perspective, the GROUP BY of SQL, why do you have to replicate the group by columns in the select columns?:
SELECT <key column list>, Min(<col1>), Max(Col1) --Why do we need to specify <key column list>?
FROM <table>
GROUP BY <key column list>
Instead of:
SELECT <Aggregate column list>
FROM <table>
GROUP BY <key column list>
Or if we follow a top down approach to SYNTAX:
FROM <table>
GROUP BY <key column list>
SELECT <Aggregate column list>
Just my 2c.
LJ
I actually also think the Linq way is more logical compared to SQL.
My logic for SQL would actually be that the SELECT statement syntax is executed as a TOP to BOTTOM logic, e.g.:
FROM <table> [WHERE <tablewhere>][, <tablelist>]
WHERE <This will hold relationship constraints>
SELECT <column list>
Or from my perspective, the GROUP BY of SQL, why do you have to replicate the group by columns in the select columns?:
SELECT <key column list>, Min(<col1>), Max(Col1) --Why do we need to specify <key column list>?
FROM <table>
GROUP BY <key column list>
Instead of:
SELECT <Aggregate column list>
FROM <table>
GROUP BY <key column list>
Or if we follow a top down approach to SYNTAX:
FROM <table>
GROUP BY <key column list>
SELECT <Aggregate column list>
Just my 2c.
LJ
______________________
Johan Nel
Boshof, South Africa
Johan Nel
Boshof, South Africa
LINQ
Nick & al.,NickFriend wrote:Following on from what Otto said...
It's only a problem if you approach it with the screwed up logic of SQL
Nick
never thought i might speak "pro SQL" - but given that the world is full of SQL and minds that think screwed for years, it is really a typical MS solution, for ease of intellisense to invent another way of expressing things...
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
- Phil Hepburn
- Posts: 743
- Joined: Sun Sep 11, 2016 2:16 pm
LINQ
Hi George and all,
Yes, the LINQ syntax does seem a bit different at first, and particularly to SQL guys. However, I can say that once you get into LINQ it soon becomes second nature, easy, and quite likeable too.
One nice thing about LINQ is that if you then use Entity Framework 6 / 7 +, then you do not need to go back and use SQL queries ever again - just do everything from LINQ and .NET X# code.
There are also some nice features which help the standard user (which is what I class myself as), like using one query variable within another, to simplify the first query. Also, under the hood the compiler does actually turn this query syntax into an SQL statement, or query to be sent to the SQL engine when we are using EF. We can easily see the SQL statement which the compiler generates.
I found that quite often the SQL statement created and used by the compiler looks nothing much like the LINQ code I create and use. It does some very clever stuff, optimizing as well.
Are you ready for this comment of mine ? "LINQ in .NET is fun to use" ;-0)
Cheers,
Phil.
Yes, the LINQ syntax does seem a bit different at first, and particularly to SQL guys. However, I can say that once you get into LINQ it soon becomes second nature, easy, and quite likeable too.
One nice thing about LINQ is that if you then use Entity Framework 6 / 7 +, then you do not need to go back and use SQL queries ever again - just do everything from LINQ and .NET X# code.
There are also some nice features which help the standard user (which is what I class myself as), like using one query variable within another, to simplify the first query. Also, under the hood the compiler does actually turn this query syntax into an SQL statement, or query to be sent to the SQL engine when we are using EF. We can easily see the SQL statement which the compiler generates.
I found that quite often the SQL statement created and used by the compiler looks nothing much like the LINQ code I create and use. It does some very clever stuff, optimizing as well.
Are you ready for this comment of mine ? "LINQ in .NET is fun to use" ;-0)
Cheers,
Phil.
- Attachments
-
- AnonTypes_13.jpg (29.37 KiB) Viewed 577 times
-
- AnonTypes_24.jpg (59.42 KiB) Viewed 577 times
-
- AnonTypes_25.jpg (77.76 KiB) Viewed 577 times