3 ms·

> writing SQL for CRUD is really repetitive and tedious If you think of relational DBs as just CRUD machines, an ORM makes total sense, but that's the original

> writing SQL for CRUD is really repetitive and tedious If you think of relational DBs as just CRUD machines, an ORM makes total sense, but that's the original mistake.

audunw 3y ago
Is it a mistake if that's all you need? I'm kind of on the side of avoiding ORM unless you have a clear need for it. But I've seen projects where they are very valuable. If you mainly want to register, update and delete a bunch of structured data, it's not a bad idea to put it in a dabatase. And if you do those operations a lot in some part of the application, it's not a bad idea to use an ORM there. For analysis and reports and such I would probably suggest just writing SQL directly though.
- hot_gril 3y ago
  Yeah, part of an application might be CRUDing big pieces of structured data, and for that I think jsonb is the best compromise (https://news.ycombinator.com/threads?id=hot_gril#37123355 https://news.ycombinator.com/threads?id=hot_gril#37123355). Comes with the limitation that you can't have FKs into the objects, but you shouldn't anyway. It's hard to be sure that CRUD is all you need. Maybe you'll be fine, maybe you'll get stuck between keeping a slow DB or rewriting everything (I've seen this movie several times). It doesn't cost much to go proper relational from the start, especially cause that involves the least tooling/boilerplate. And if you're really sure you only want objects, NoSQL DBMSes are actually designed for that.
TX81Z 3y ago
I think that’s part of why I’m having trouble with this framing - it’s treating CRUD as the entire universe of why you’d need to connect to a database. Some of us do very intense compute in very large datasets, and ORM are not capable in those tasks. At all.
- hot_gril 3y ago
  Doesn't even have to get very intense. A simple timeseries schema gets slow/annoying quickly with an ORM.
  - TX81Z 3y ago
    I think for a lot of things an ORM is “good” at, you could likely just have a bunch of static JSON files and retrieve them from disk with zero practical difference. I just can’t wrap my head around why you even *need* a database in those cases.
    - hot_gril 3y ago
      Honestly I wouldn't deal with JSON files on disk except as a last resort. Aside from convenience, you need a DB for transactional reads/writes. But you don't need an ORM for that anymore because Postgres and MySQL have json/jsonb types.

> writing SQL for CRUD is really repetitive and tedious If you think of relational DBs as just CRUD machines, an ORM makes total sense, but that's the original mistake.

audunw 3y ago

Is it a mistake if that's all you need? I'm kind of on the side of avoiding ORM unless you have a clear need for it. But I've seen projects where they are very valuable. If you mainly want to register, update and delete a bunch of structured data, it's not a bad idea to put it in a dabatase. And if you do those operations a lot in some part of the application, it's not a bad idea to use an ORM there. For analysis and reports and such I would probably suggest just writing SQL directly though.

hot_gril 3y ago
Yeah, part of an application might be CRUDing big pieces of structured data, and for that I think jsonb is the best compromise (https://news.ycombinator.com/threads?id=hot_gril#37123355 https://news.ycombinator.com/threads?id=hot_gril#37123355). Comes with the limitation that you can't have FKs into the objects, but you shouldn't anyway. It's hard to be sure that CRUD is all you need. Maybe you'll be fine, maybe you'll get stuck between keeping a slow DB or rewriting everything (I've seen this movie several times). It doesn't cost much to go proper relational from the start, especially cause that involves the least tooling/boilerplate. And if you're really sure you only want objects, NoSQL DBMSes are actually designed for that.

TX81Z 3y ago

I think that’s part of why I’m having trouble with this framing - it’s treating CRUD as the entire universe of why you’d need to connect to a database. Some of us do very intense compute in very large datasets, and ORM are not capable in those tasks. At all.

hot_gril 3y ago
Doesn't even have to get very intense. A simple timeseries schema gets slow/annoying quickly with an ORM.
- TX81Z 3y ago
  I think for a lot of things an ORM is “good” at, you could likely just have a bunch of static JSON files and retrieve them from disk with zero practical difference. I just can’t wrap my head around why you even *need* a database in those cases.
  - hot_gril 3y ago
    Honestly I wouldn't deal with JSON files on disk except as a last resort. Aside from convenience, you need a DB for transactional reads/writes. But you don't need an ORM for that anymore because Postgres and MySQL have json/jsonb types.