SQL Abstraktion #¥#

ORMs are fucking shit for anything but the most basic cookie cutter crud application. Once you need to do anything complex or optimize the queries you'll wish you just used raw SQL.

Okay I’ll bite:

There is no REALLY good way to do it. I’ve screwed around a lot with this, part hobby, part work. Here’s my experience.

You can return ‘dead’ data classes/containers, so there’s a table, a struct/data object, and maybe some adapter for initialisation (unless your table row matches your data type exactly, but in that case just work with whatever sql returns to you).
This works but you either have to

- Resolve foreign keys during read operation. Problem foreign keys can be circular in many databases, so you get infinite recursion (eg: some ‘post’ object has a ‘category’ field but the ‘category’ object has many ‘posts’, ... )

- Create member function(s) to resolve foreign keys on request. But this almost beats the purpose, as only the user knows what exactly he intends with it.

- Dynamically add a resolution function to the retrieved object that resolves the foreign key: this requires many hacks in most languages.

In any case, you’ll see that a lot of stuff moves to application code as relations become too complex. Most ORM either do/resolve very little, or let you write almost pure SQL to ‘declare’ your DB items.

Personally I now prefer a really simple system where you declare which fields you want to from what table and a pointer to an initialisation function or just return the fields as a hashmap.
Foreign key resolution goes on the application side.

That is true if you stay simplistic (basic CRUD). But all ORM produce garbage SQL if you go into sane degree of data modelling where performance counts and need/want to use DB specific SQL functions.

The plus being db agnostic is not true in real world as you will not replace a rdbms in an enterprise environment every other week.

ORMs are only needed because OO doesn't map to databases or reality.

Attached: 1563994390620.jpg (1275x1806, 180K)

Django wanted me to define my tables in python and it would handle the creating and management of the database side of things.
This stuck me a ass-backwards as I may have already had a database with multiple users that I simply wanted to interface to.

Sometimes you gotta throw in a few raw dog pumps tho

There's a lot of projects that generate code from an existing DB schema though.

Using EF to do some more or less complex CRUD stuff, works just fine after dealing with some EF specific quirks (it's single thread for one). DB is defined in pure SQL, C# models are autogenerated from this definition. I won't let EF touch my schema.

It's a sane work envitronment now.

retarded anime poster.

Yes, Using Category Theory.
categoricaldata.net/cql/oracle.pdf
categoricaldata.net/

arxiv.org/abs/1803.05316

God I hate ORMs.

We also use EF across our application, but we manually create the C# models, gives a little more control of what we can put in the DB at the cost of initial coding time, we also have a heavier API and light UI code, as opposed to the opposite

but all the cool kids are webscale?

Dogshit slow though

dbe agnosticism is important when you're writing software that might be run by both regular jackholes and businesses. Jackhokes probably just need sqlite, but a user who is really making use of your application might be using postgres, mariadb, SQL Server or Oracle. Being able to support all of these can really smoothen out the sales and deployment process.
But you're generally right. 99% of shit only needs to support one dbe.

wait, is this Ruby on Rails?
We don't like faggots in /g

ActiveRecord can be used outside Rails but yes generally it is Rails fags who use it

ORMs are for diaper-wearing queers who are too retarded to write SQL queries (ie room temp IQ and above).
Also you don't know wtf you're talking about, gb2 to the /webdev/ general gaypile and stay there.
>Django's ORM is mostly sane
Definitely more sane and convenient than most ORMs
>OO doesn't map to databases or reality.
based coomer
OO is harmful af

you can do that with functions, you fucking retard.

>dude don't use ORM lmao
guys, knowing SQL is still valuable, don't be so fucking insecure, there's absolutely no negative to using an ORM, think, if you need to optimize a certain query, then just use the fucking raw query option most ORM provide, don't fucking re-invent the wheel.

LOL you fucking retarded Laravel sperg can fuck right off. Yes you heard me, not even websites with little white aliens like you. Fuck off Mr. Otwell you retarded cocksucker. Watcha gonna do? Delete your account again?

that syntax looks like shit. why does it have to be an autistic syntax with you fucks?

Why not just use the C-family syntax like any other relevant programming language.

I think ORMs are good because its better to pass around OO objects than raw sql data, and since you will be mapping sql data to objects in every project you may as well have a framework do it.

ORMs piss me off though because people say they abstract away from icky SQL but sometimes the way they do it is so much different from SQL (like criteria queries for example) that its like learning SQL part 2

Your sw architecture most of the time has abstractions from your storage systems. Usually the whole database stuff is seperated from your domain models. This allows you to "tune" your data models for specific needs and to exchange it while your domain models are uneffected by it. Also SQL is just a language most RDBMS understand. Saying you should use an ORM is mixing things together and misses the question. Ofc don't consume user inputs unfiltered and unchecked but op was asking for abstractions not security.

>he doesn't know webscale
wew you're new babes