SQL sucks as a language, no wonder there are countless ORM's trying to abstract it away!

SQL is fine, ORMs turn it into shit.

@IntrusionCM are you serious? This shit looking like cobol clone with 100+ special keywords that can be inserted next to other keywords which honestly nobody know which ones can be combined or what is their effect because there's too many possibilities. And you call that fine? I can tell that I like the relational stuff, the joins etc, but the language is some sadistic bullshit and it's no point denying that.

@onslaught

Oh the language makes absolute sense.

It just requires learning it.

There's nothing sadistic in it.

@IntrusionCM if the sql language is fine then why would people do so much effort in creating many ORMs just to avoid sql. It does not make much sense to me.

@onslaught

Object Relational Mapper.

It has nothing to do with being against SQL.

More to do with the very hard part of trying to convert relational data to an object oriented approach.

By the way: That is the sadistic part.

Cause the conversion is mostly where shit explodes.

Active Row Pattern, Unit of Work, Serialization / Deserialization (or Hydration), Repositories, CQRS, Projection, ...

A lot of things happen in an ORM (or are realized by it)

The ultimate truth about an ORM is that the approach will never be perfect.

Compromises must be made and most of the time the ORM side will be the side that gives you a fucking migraine.

Starting with lovely things like N+1 problem, wrong / bad conversion to SQL (e.g. usage of functions which prevent index usage), funky memory problems, batch insertion not working like it should etc.

Honestly, SQL is much easier and simpler to use and understand. ORMs look cool but adds more headache and consume more time than you have

@ostream you are looking for your age group to play in the park?

SQL > ORM

SQL ain't bad at all, you just have to take the time to learn it properly. After that, sure, you'll occasionally run into variations specific to various RDBMS's that might make you screech a bit, but the basics don't change and those aren't terribly hard to grasp.

It's MUCH better than the "gee, I hope this overly-complex piece of garbage ORM doesn't totally shit the bed coming up with the model and costing me massive time and money to detangle the mess enough for the app to work decently" paradigm. Sure, you could have probably MADE it do what you needed from the start by using this ORM's specific concepts, but then good luck moving to a new one.

No, gimme SQL every day of the week and twice on Sunday over any ORM on the planet.

And, ironically, looking like COBOL is a feature, not a bug. When did it become necessary for code to look like motherfucking CODE that we have to hire Windtalkers to understand?! Fuck all this modern symbology bullshit!

@IntrusionCM > "More to do with the very hard part of trying to convert relational data to an object oriented approach."

I don't know what magic they got going on under the hood, Dapper has been our silver bullet for a long time.

@PaperTrail

https://github.com/DapperLib/...

An ORM usually has CRUD and other things integrated, from pure glancing over it they made the very wise choice to not do this.

Mostly it's called a unit of work / session.

It's a complicated thing - simplified speaking, it tracks what happens with an object during it's lifetime and synchronizes changes to the database.

Dapper has no such function in its base library. It focuses solely on mapping and creating objects.

The tracking of an object lifecycle is what usually allows the active row pattern: An object is then an entity, an entity represents a row of a database table and basic crud functions like .persist, .fetch, ... exist. That tracking is where a lot of grief stems from... Fun stuff like transaction handling, memory related issues, connection session handling, handling of object references etc

@IntrusionCM > "they made the very wise choice to not do this."

Agreed. We have the luxury of having a team of DBAs that optimize the crap out of the database so all the CRUD 'stuff' is handled in stored procs. For complex/large mappings, Dapper kicks EF (Entity Framework for the non C# folks) butt every single time. Maybe there has been improvements since we've last benchmarked, but I can't ever see us using a 'real' ORM. YMMV.

This one is a hot take for sure. I don't dislike SQL, what I do dislike is the error messages provided by all the major engines.

And MySQL has some of the worst error messages imo

@AleCx04

C++ template instantiation errors say hi.

As for OP, had he bothered to RTFM just a bit instead of bulldozing through life with npm i, he'd have realized SQL *itself* is already an abstraction over a bunch of set mathematics, and that ORMs, for reasons I won't bother repeating, are just a way of picking your poison.

I will agree on one point: complex SQL can get really, really bad.1-6 lines can read like English and be nearly immediately understood.

Anything more than that, with left, right, inner joins, grouping, subqueries, unspoken Cartesian joins... SQL really lets you make a TOTAL mess out of it, and sometimes making a grubby mess of a query is the only/best way.

I think in comparison, something like Linq is pretty gross. What the fuck does

.Where(e => e.ID == recordID)

Even mean? Oh, it's a shorthand lambda in a where clause? We're back to 1-letter-variables as a standard now? Great. Who let that one slip past QA??