logoalt Hacker News

const_cast • yesterday at 2:36 AM • 1 reply • view on HN

> In my eyes, it’s pretty simple: use the ORM for the simple CRUD and simple data querying, because you’ll have to do a lot of it in most codebases.

The "danger" here is the movement towards an object-oriented design instead of a SQL-first approach to querying the database.

In my experience, I have seen ORMs used for these simple CRUD cases and what tends to happen is you have objects with dozens of members when you only need one or two. And then down the line you also start doing JOINs in memory - you just don't recognize it like that.

You see, you get Object X using CRUD and then object Y using CRUD and then you need a way to say which relates to what and... oops now we've done joins in memory. And sometimes, maybe even often times, we're doing all of that for a single field we need in this one place.

Replies

KronisLV • yesterday at 8:23 AM

> The "danger" here is the movement towards an object-oriented design instead of a SQL-first approach to querying the database.

That might just be an inherent problem with object oriented languages, you probably have some mapping that you need to do even with raw SQL and before long you'll have the same use cases emerge.

Whether that means any of the following is true:

  OOP is bad for interacting with SQL
  SQL is bad for being used by OOP (or rather, relational databases, maybe not object stores)
  other approaches might help make it less bad, but ORMs don't help in common usage
  maybe we just don't have the right pattern yet, perhaps the "object relational impedance mismatch" folks have a point
I can't tell, not even sure what a proper solution would be.

I've seen what happens when people try to put all of the business logic inside of the DB and it's absolute trash (from the perspective of developer experience, versioning, debugging etc.; the performance was actually stellar) to work with.