this post was submitted on 23 Mar 2025
260 points (100.0% liked)

LinkedinLunatics

4181 readers
4 users here now

A place to post ridiculous posts from linkedIn.com

(Full transparency.. a mod for this sub happens to work there.. but that doesn't influence his moderation or laughter at a lot of posts.)

founded 2 years ago
MODERATORS
[email protected]
[email protected]
260
Liking any of these indicates a belief system I don't agree with (sopuli.xyz)
submitted 5 days ago by [email protected] to c/[email protected]
79 comments fedilink hide all child comments
 

cross-posted from: https://sopuli.xyz/post/24303260

URL: https://www.linkedin.com/posts/michelesollecito_in-my-own-company-i-wouldnt-hire-anyone-activity-7309491565603835904-uBhX

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 25 points 5 days ago (3 children)
  • ORM's
  1. Place ALL of the business logic in stored procedures.
  2. Eliminate the backend.
  3. Make the front end connect directly to the database.
  4. ~~Profit~~
  5. Introduce tons of bugs and terrible performance.
  6. Database is compromised within five minutes of going live.
[–] [email protected] 6 points 4 days ago (1 children)

I'm confused. Are you saying all of that is a consequence of not using ORMs? Because if so, that's absolutely not true. ORMs truly are complete trash.

[–] [email protected] 3 points 4 days ago (1 children)

Sounds like you were hurt by an ORM.

One huge benefit of an ORM is that it does type checking. it makes sure your tables exist, relationships are valid, etc, and it makes easy things easy. If you add a column, it'll make sure it gets populated, give you decent error messages, etc.

As long as you use a proper repository pattern setup and isolate DB interactions from the rest of the code, how you construct the queries is completely up to you. I try to use DTOs to communicate w/ the repo layer, so whether an ORM is used or direct SQL queries is largely an implementation detail.

[–] [email protected] 2 points 3 days ago (1 children)

https://github.com/launchbadge/sqlx

Not an ORM, but uses Rust's compile time macros so you can write raw SQL and it will type check everything against either a real database connection or a JSON cache of the database's schema.

Absolute best of both worlds.

[–] [email protected] 2 points 3 days ago

That sounds really nice, I'll have to check it out.

[–] aubeynarf 7 points 5 days ago* (last edited 5 days ago) (1 children)

No, just write a repository to expose domain operations and implements them using SQL directly. Trying to fake OO object graphs against a RDBMS with a super-complex and leaky ORM is just painful.

[–] [email protected] 1 points 5 days ago (2 children)

Would you classify GORM that way?

[–] aubeynarf 2 points 5 days ago (1 children)

Groovy’s ORM? I recall it being Hibernate under the hood and I had to fight with it to avoid common problems like hidden IO and N+1 query blowups (iterating over a set of results and then touching the wrong property means you are making another network call for each), learning its particular DSL for schema definition and associations, and not having a way to represent any but the simplest SQL constructs. The usual ORM stuff.

To the extent that you can write a syntax-checked SQL statement and it deserializes the results into some collection of row objects, it’s fine. But that’s not the “ORM” part.

[–] [email protected] 2 points 5 days ago (1 children)

GORM is Go ORM

[–] aubeynarf 3 points 5 days ago

I have not used that GORM, but ORMs have those problems generally.

[–] [email protected] 1 points 5 days ago

i prefer going GORMLESS

[–] [email protected] 4 points 5 days ago (2 children)

I have for years been pumped to create a sql only side project or sql + frontend

[–] [email protected] 1 points 4 days ago

Please don't. I self-host actual budget, and they compile SQLite to WASM to use it in the FE. That just feels... wrong.