3 ms·

LINQ was/is fantastic. Being able to run queries over data without having to implement the various boilerplate is excellent. Unfortunately basic mistakes can

LINQ was/is fantastic. Being able to run queries over data without having to implement the various boilerplate is excellent. Unfortunately basic mistakes can result in so many of those N+1 type queries if you're not careful. It can also result in reading entire table(s), possibly inside those nested N+1s. It gets expensive when it's a remote DB server and/or dealing with a lot of records. Profiling tools are essential. It's why I'm not a fan of LINQ (and Entity Framework) for talking to DB severs without very strict controls. Many times I've been called in to deal with a "slow" server, only to find out the issue is someone chained together a bunch of calls through EF and we have hundreds of thousands of queries that can be replaced by one or two.

scarface_74 3y ago
And that also happens with SQL - which is also an abstraction.
- sgarland 3y ago
  SQL is only an abstraction if you consider modifying the physical file to be the purer form of RDBMS manipulation.
  - scarface_74 3y ago
    Would you consider SQL an abstraction over DynamoDB? ElasticSearch’s native query language? Apache Presto to query files? Mongo? All of those can use SQL as a worse query language than their native counterparts. You can also create very bad SQL if you don’t know the underlying engine. For instance if you try to write SQL for a columnar database like you would for a traditional database, you are in for a world of hurt.
    - paranoidrobot 3y ago
      You seem to be talking about databases who's native language is not SQL. In those cases, yes, SQL is definitely an abstraction. There's some layer that's transforming that into (say) Elastic query or Dynamo queries. I would argue that when talking about writing SQL, most folks are talking about applications who's query planner talks some dialect of SQL. MS SQL Server, MariaDB, MySQL, Oracle, SQLite. In those cases, it's not really an abstraction any more than writing assembly is an abstraction over (say) Intel's CPU microcode is. The query planner takes your SQL and turns it into something else, sure, but you can't generally do that yourself. It's the lowest layer of abstraction that's reasonably available.
      - deleted 3y ago
        [deleted]
useerup 3y ago
> Unfortunately basic mistakes can result in so many of those N+1 type queries if you're not careful. It can also result in reading entire table(s), possibly inside those nested N+1s. I don't know which "basic mistake" would do this. Maybe when using Lazy loading Proxies? We use EF Core and it is quite easy to control eager loading or load-on-demand on a per-case basis.

scarface_74 3y ago

And that also happens with SQL - which is also an abstraction.

sgarland 3y ago
SQL is only an abstraction if you consider modifying the physical file to be the purer form of RDBMS manipulation.
- scarface_74 3y ago
  Would you consider SQL an abstraction over DynamoDB? ElasticSearch’s native query language? Apache Presto to query files? Mongo? All of those can use SQL as a worse query language than their native counterparts. You can also create very bad SQL if you don’t know the underlying engine. For instance if you try to write SQL for a columnar database like you would for a traditional database, you are in for a world of hurt.
  - paranoidrobot 3y ago
    You seem to be talking about databases who's native language is not SQL. In those cases, yes, SQL is definitely an abstraction. There's some layer that's transforming that into (say) Elastic query or Dynamo queries. I would argue that when talking about writing SQL, most folks are talking about applications who's query planner talks some dialect of SQL. MS SQL Server, MariaDB, MySQL, Oracle, SQLite. In those cases, it's not really an abstraction any more than writing assembly is an abstraction over (say) Intel's CPU microcode is. The query planner takes your SQL and turns it into something else, sure, but you can't generally do that yourself. It's the lowest layer of abstraction that's reasonably available.
    - deleted 3y ago
      [deleted]

useerup 3y ago

> Unfortunately basic mistakes can result in so many of those N+1 type queries if you're not careful. It can also result in reading entire table(s), possibly inside those nested N+1s. I don't know which "basic mistake" would do this. Maybe when using Lazy loading Proxies? We use EF Core and it is quite easy to control eager loading or load-on-demand on a per-case basis.