Hacker News Reader

Comment by paranoidrobot | Hacker News Reader

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.

View on HN

> 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.

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

SQL is only an abstraction if you consider modifying the physical file to be the purer form of RDBMS manipulation.

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.

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.

Reply on news.ycombinator.com