7 ms·

Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, save

Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface. Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will make it worse.

deleted 7y ago
[deleted]
chipotle_coyote 7y ago
Programmer without anything in particular to prove: hey, I already know SQL, and ORMs create queries "under the hood" in ways I can reason about and control, so I'm going to use this ORM in a way that doesn't involve just throwing objects and tables together in a big pile and mooshing them all together with duct tape.
- sjwright 7y ago
  One of the biggest reasons why I don't use ORMs is because I try to avoid using objects at all unless there's a really good reason to do so. And when I forget to follow that principle it has always turned out to be a mistake; de-objectifying has consistently resulted in simpler, shorter code with fewer data bugs. My working principle is to have data spend as little time as possible being thrown around within application code. I tend to find that the longer data spends being sieved through layers and tossed around inside your application, the more data bugs you'll end up having. And when it comes time to display data to the user, it's rarely inconvenient to write an SQL query that fetches exactly what you want to display in exactly the right format and exactly the right order—obviating the need to have any "objects" that "understand" your data model. The problem is that far too few programmers realise how deep the SQL rabbit hole goes; it's treated like a little side-hustle like regular expressions, when for so many programmers it's the most valuable skill to level up.
graphememes 7y ago
10x programmer: I used a tool and it did all the work and now I can move on to the next thing
- lugg 7y ago
  Clojure programmer: I'm never going to run out of work replacing these 10x masterpieces.
deleted 7y ago
[deleted]
- deleted 7y ago
  [deleted]
fastball 7y ago
What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.
- taffer 7y ago
  > What ORM do people use that influences the structure of their database? Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. > Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON. Postgres has great JSON support, does the ORM something with JSON that Postgres cannot do?
  - stickfigure 7y ago
    Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. This is not true. There's a culture of doing that in demos, but every production shop I've ever been in curates DDL by hand. Flyway is pretty popular.
  - shkkmo 7y ago
    > Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. This is a feature, not requirement or need of the ORM. It seems pretty silly to let the existence of a feature prevent you from making designing the structure of your DB correctly. > does the ORM something with JSON that Postgres cannot do? Postgres's json functionality is used for manipulating and querying data stored in the DB. I believe the poster is talking about deserializing and validating json from REST requests and serializing json for REST responses using the mapping defined for the ORM.
    - taffer 7y ago
      > I believe the poster is talking about deserializing and validating json from REST requests and serializing json for REST responses using the mapping defined for the ORM. These are also things that the json functionality of Postgres can do. For example, look at to_json and json_agg.
mst 7y ago
If your ORM influences your database structure, either your ORM is shit or you don't know how to use it yet. ... or both. Both is always a possibility. Welcome to programming.
- sjwright 7y ago
  If the object reasoning inherent in ORM design isn’t influencing your structure, either your structures are trivial or you don’t know how to use the full capabilities of your engine yet. ... or both. Both is always a possibility. Welcome to databases.
  - oefrha 7y ago
    Most perfectly viable database schemas in the real world are trivial by your definition of trivial. Trivial designs aren’t necessarily bad designs; sometimes quite the opposite. Thanks for the condescension though.
    - sjwright 7y ago
      I don't disagree with anything you've said. Though I might raise a very minor objection to the unspoken implication that the "most" database schemas which are currently trivial should be trivial. You're right that trivial designs are very often preferable. But I would hasten to add that when the application calls for data correctness, a bias towards triviality can occasionally manifest as a trade-off between complexity on the application side and complexity on the database engine side. (As for the condescension, I agree with that too. It was aimed squarely at the GP in the marginal hope that he gets to experience his own tone mirrored back at himself. It might just offer him some insights into perspective.)
      - mst 7y ago
        Personally, I find that when I run into a problem while programming and ask myself "is this library being stupid or am I?" it's rather useful to remember that "both" is always a possibility. Of course, it's the internet, so dry british cynicism and condescension aren't as trivially distinguishable as one might hope. Sorry my tone didn't come across correctly.
scarface74 7y ago
Until you have a grid with a filter in your UI where the user can create a dozen different queries on the fly.... Why does your database structure have to be structured by your ORM? The only ORM that I have used are LINQ based ones and they can model any database relationship. Don’t get me wrong, my first instinct when starting a project is to use Dapper - a Micro ORM written by Stack Overflow that just maps a sql query result to object and doesn’t generate sql.

deleted 7y ago

[deleted]

chipotle_coyote 7y ago

Programmer without anything in particular to prove: hey, I already know SQL, and ORMs create queries "under the hood" in ways I can reason about and control, so I'm going to use this ORM in a way that doesn't involve just throwing objects and tables together in a big pile and mooshing them all together with duct tape.

sjwright 7y ago
One of the biggest reasons why I don't use ORMs is because I try to avoid using objects at all unless there's a really good reason to do so. And when I forget to follow that principle it has always turned out to be a mistake; de-objectifying has consistently resulted in simpler, shorter code with fewer data bugs. My working principle is to have data spend as little time as possible being thrown around within application code. I tend to find that the longer data spends being sieved through layers and tossed around inside your application, the more data bugs you'll end up having. And when it comes time to display data to the user, it's rarely inconvenient to write an SQL query that fetches exactly what you want to display in exactly the right format and exactly the right order—obviating the need to have any "objects" that "understand" your data model. The problem is that far too few programmers realise how deep the SQL rabbit hole goes; it's treated like a little side-hustle like regular expressions, when for so many programmers it's the most valuable skill to level up.

graphememes 7y ago

10x programmer: I used a tool and it did all the work and now I can move on to the next thing

lugg 7y ago
Clojure programmer: I'm never going to run out of work replacing these 10x masterpieces.

deleted 7y ago

[deleted]

deleted 7y ago
[deleted]

fastball 7y ago

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

taffer 7y ago
> What ORM do people use that influences the structure of their database? Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. > Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON. Postgres has great JSON support, does the ORM something with JSON that Postgres cannot do?
- stickfigure 7y ago
  Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. This is not true. There's a culture of doing that in demos, but every production shop I've ever been in curates DDL by hand. Flyway is pretty popular.
- shkkmo 7y ago
  > Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that. This is a feature, not requirement or need of the ORM. It seems pretty silly to let the existence of a feature prevent you from making designing the structure of your DB correctly. > does the ORM something with JSON that Postgres cannot do? Postgres's json functionality is used for manipulating and querying data stored in the DB. I believe the poster is talking about deserializing and validating json from REST requests and serializing json for REST responses using the mapping defined for the ORM.
  - taffer 7y ago
    > I believe the poster is talking about deserializing and validating json from REST requests and serializing json for REST responses using the mapping defined for the ORM. These are also things that the json functionality of Postgres can do. For example, look at to_json and json_agg.

mst 7y ago

If your ORM influences your database structure, either your ORM is shit or you don't know how to use it yet. ... or both. Both is always a possibility. Welcome to programming.

sjwright 7y ago
If the object reasoning inherent in ORM design isn’t influencing your structure, either your structures are trivial or you don’t know how to use the full capabilities of your engine yet. ... or both. Both is always a possibility. Welcome to databases.
- oefrha 7y ago
  Most perfectly viable database schemas in the real world are trivial by your definition of trivial. Trivial designs aren’t necessarily bad designs; sometimes quite the opposite. Thanks for the condescension though.
  - sjwright 7y ago
    I don't disagree with anything you've said. Though I might raise a very minor objection to the unspoken implication that the "most" database schemas which are currently trivial should be trivial. You're right that trivial designs are very often preferable. But I would hasten to add that when the application calls for data correctness, a bias towards triviality can occasionally manifest as a trade-off between complexity on the application side and complexity on the database engine side. (As for the condescension, I agree with that too. It was aimed squarely at the GP in the marginal hope that he gets to experience his own tone mirrored back at himself. It might just offer him some insights into perspective.)
    - mst 7y ago
      Personally, I find that when I run into a problem while programming and ask myself "is this library being stupid or am I?" it's rather useful to remember that "both" is always a possibility. Of course, it's the internet, so dry british cynicism and condescension aren't as trivially distinguishable as one might hope. Sorry my tone didn't come across correctly.

scarface74 7y ago

Until you have a grid with a filter in your UI where the user can create a dozen different queries on the fly.... Why does your database structure have to be structured by your ORM? The only ORM that I have used are LINQ based ones and they can model any database relationship. Don’t get me wrong, my first instinct when starting a project is to use Dapper - a Micro ORM written by Stack Overflow that just maps a sql query result to object and doesn’t generate sql.