6 ms·
This is one of the things MS Entity Framework gets right - it enforces the "start with FROM". It actually ends with SELECT, which makes so much more sense. Se
by Pxtl 7y ago
This is one of the things MS Entity Framework gets right - it enforces the "start with FROM". It actually ends with SELECT, which makes so much more sense.
Seriously, between navigational properties, group-with-children, EF to me hammers home how bad SQL is. EF is a square peg in a round hole but it does a great job at makign some trivial improvements over SQL, while still remaining true to the principles of relational databases.
Of course, the framework is a hairy mess for other reasons (lazy loading, untranslateable methods, ugly generated queries) but the alternative to SQL it presents is lovely.
- munk-a 7y agoI do prefer this structure, but it differing for this one product is more of a cost than I'd like to pay for it. SQL is wonderful because so much of it is platform independent - nearly everything can be expressed in a common SQL manner and, in practice, I tend to avoid dialect specific SQL whenever possible - this just ups the comprehension immensely. There are a bunch of tech that's tried to reinvent the wheel with SQL like Redis and Splunk... both of those systems are just a pain to interact with - their variants have strengths, sure, but they lose the ease of declaration and universality of SQL. I'd rather see a SQL variant emerge (if it were to) as a logically compatible declarative language that various DB vendors can add support for.
- nightski 7y agoThe thing is that LINQ's purpose is not to reinvent SQL. While EF has an adapter which converts LINQ expressions to SQL, you can use LINQ against objects and other sources for which it is incredibly useful. In fact, it's better suited to those tasks as it doesn't map 1:1 with SQL. But as someone who uses EF and LINQ on a daily basis, it is possible to learn how the mapping is performed and get the results you want consistently even in some pretty advanced scenarios.
- scarface74 7y agoSide note, I fell in love with the Mongo LINQ driver. There is no impedance mismatch. While I never used LINQ to avoid learning sql, I would create my complex Mongo queries in LINQ first.
- jessaustin 7y agoWould there be any conceptual barrier to a particular DB engine getting an updated parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."?
- nojvek 7y agoThere shouldn’t be. Engines don’t run sql directly. They make an AST, make an intermediate representation of instructions and then execute. So if it results in same AST, the parser should be flexible. Someone should make PRs for mysql, slqlite and Postgres. If those three have it, other engines will catch up real fast.
- mariushn 7y agoI started a discussion at https://www.postgresql.org/message-id/CAPUEYuYuJSRE_c_k%2BuBQReKUDZOMb3niiJ3mPuDP6AFdK_%2Bpiw%40mail.gmail.com https://www.postgresql.org/message-id/CAPUEYuYuJSRE_c_k%2BuB...
- quickthrower2 7y agoWhat do you mean SQL is bad? SQL is very good and some dialects can do some amazing things. I don't think EF is much better, and EF (older Linq2Sql as well) has some gotchas because it converts your expression into SQL, except for when it doesn't and throws a runtime error that it couldn't. And there are some edge cases where you think a C# expression would convert to SQL but alas, it wont.
- manigandham 7y agoThe point is that LINQ expressions (in the query syntax) can be more readable and straightforward than the equivalent statement in SQL. EF is just an ORM that benefits from using the LINQ syntax and operators available in .NET/C#.
- quickthrower2 7y agoThanks. Even on just that point, I disagree. I think they are equally readable. Just like Python and C# are equally readable to the respective cohorts that are used to programming in those languages. Yes, EF queries are more readable to many developers who know C# well but don't want to get used to SQL. But the problem with that is DB apathy + EF leads to some real performance problems as systems scale that grinds the application to a halt with SQL queries longer than dissertations, to which the developers need a quick hack to fix. The query plan for those beasts is intractable. Which of the 10 table scans or index scans to tackle first? And how do you tackle it? They discover "indexed views" and all is well until you start to have locking problems, so more hacks are needed. etc. By writing the damn SQL to begin with they'd have to tame the beast earlier on and address the design flaws in their schema and/or application. Ok this is a bit of a strawman (although it is based on experience) but I think saying SQL is less readable is a red herring. It is more readable for a lot of use cases. It's a DSL designed for the job, you really can't get much better (except for Elastic Search use cases, etc.). It's slightly old fashioned but that's just fashion.
- manigandham 7y agoThis isn't about ORMs or database performance. It's just a comparison of query languages, with LINQ being more natural for data models with lots of joins and nested records that are common today (especially since that's how people work with objects inside their programming language). SQL is far from perfect. It would be nice to see some modern SQL dialects that follow the LINQ syntax and are natively supported by RDBMS.
- tehlike 7y agoTechnicality, but it is not ef, it is the way linq is designed.
- balfirevic 7y agoIt's an important point, LINQ is the foundation that has applications beyond and outside of Entity Framework.
- sterileopinions 7y ago>This is one of the things MS Entity Framework gets right - it enforces the "start with FROM" It gets it "right" (right being a very loosely defined term here) by happenstance, because you're operating off of an object. Not because it was some higher level design choice or discussion.
- alexvoda 7y agoIt gets it (this order of operations issue) right because it is actually easy to get it right. It is in fact remarkable that SQL got it wrong.
- gigatexal 7y agoI wish we wrote SQL this way actually. But yes it’s the one thing the entity framework got right.
- yellowapple 7y agoElixir's Ecto makes a similar design choice, starting with the from, then joins, then filters, then a select.
- Volrath89 7y ago> Of course, the framework is a hairy mess for other reasons (lazy loading, untranslateable methods, ugly generated queries) but the alternative to SQL it presents is lovely. What is wrong with lazy loading enabled by default?
- tomnipotent 7y agoHidden side effects. Iterating over a list of something in one layer shouldn't trigger database queries in another. Ideally, you should know ahead of time what data you need and how to pre-load it without relying on something that could cause multiple N+1 issues based on the depth of lazy loading.
- flamtap 7y agoSomewhat off-topic, but if you enjoy writing LINQ to SQL (like EF), I think you will really enjoy LINQPad. https://www.linqpad.net/ https://www.linqpad.net/ It's my primary tool for querying against databases, because like you, I really prefer writing LINQ queries to SQL. It won't let you do most DB admin tasks, but that's what SSMS is for.