8 ms·
Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced
by stickfigure 7y ago
Beginning programmer: ORMs let me write code without learning SQL!
Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all.
Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.
- hinkley 7y agoThe phrase you may be searching for is 'informed consumer'. The world is full of tools that experts use because they understand what the tool is doing, and why this is a good thing... most of the time. Having the tool is a poor substitute for the knowledge that led you to use the tool instead of doing it by hand. There are times where you would not do a thing by hand and so you don't ask the tool to do it, and there are times you ask the tool to do something you would never do by hand.
- matthewmueller 7y agoI guess I'm an advanced programmer. You described my exact progression :-)
- sjwright 7y agoEven 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 agoProgrammer 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 agoOne 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 ago10x programmer: I used a tool and it did all the work and now I can move on to the next thing
- lugg 7y agoClojure programmer: I'm never going to run out of work replacing these 10x masterpieces.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- fastball 7y agoWhat 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 agoHibernate 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 agoIf 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 agoIf 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 agoMost 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 agoI 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 agoPersonally, 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 agoUntil 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.
- pjungwir 7y agoThat's pretty much exactly how I feel. I gave a talk a few years ago about doing advanced SQL things in ActiveRecord [0]. The talk suffered I think from lacking a unifying idea and because I tried to offer something to the whole spectrum of experience (from "this is a join" to "this is how you can express a CTE/lateral join/window function in AR"), but the real unifying motivation/message was that with AR you can have your cake and eat it too. I've approached tons of problems by making it work in SQL first and then translating it into AR afterwards (to some degree or other). I would reject an ORM without an "escape hatch", but AR is wonderful for taking away the boilerplate while still letting you write SQL when you need it, and even letting you make SQL more composable by defining scopes. I'm just wrapping up a couple C# projects where everything is direct SQL, and oh man is it verbose and painstaking! Every day I long for more Rails work. :-) [0] https://github.com/pjungwir/rails-and-sql-talk https://github.com/pjungwir/rails-and-sql-talk
- icheishvili 7y agoAR is the gold standard. AR + extended gem + Arel covers almost 100% of the problem space. For everything else, use views or set returning functions and wrap them up in AR.
- mst 7y agoAR took at least ten years to catch up with the perl state of the art but does seem to be doing pretty well these days.
- shade 7y agoAs a note - I've done a lot of SQL in C#, and Stack Overflow's Dapper[0] library is _fantastic_ for dealing with that. You can pass in all the SQL you like, or a stored procedure, and it deals with virtually all of the query parameterization and boilerplate around getting results out of the DB. It's saved me hours of tedium and typing. It's the perfect micro-ORM. Eliminates boilerplate, gets out of the way otherwise. [0] https://github.com/StackExchange/Dapper https://github.com/StackExchange/Dapper
- nycdotnet 7y ago
- pknopf 7y agoI really don't get why people feel like non-ORMs cause boilerplate. I write the same amount of code using Micro ORMS. Type safe. No SQL. Very happy.
- ratww 7y agoBut Micro-ORMs are ORMs. And you're right, they do remove a lot of boilerplate.
- pknopf 7y ago> But Micro-ORMs are ORMs. Not in the traditional sense. > And yes, they do remove a lot of boilerplate. Here is all the "boiler plate" you'd need to use something like OrmLite with C#. https://pastebin.com/XUhQVPUk https://pastebin.com/XUhQVPUk Type safety. No boiler plate. No abstractions. Errors are a result of the underlying data storage. This is where it's at. The sweet spot.
- mirimir 7y agoIt's been some years since I used SQL heavily. And I don't recall ever hearing about ORMs. But I certainly hated writing boilerplate. So I often used Excel and/or SQL to write my SQL. And I should add that I was using SQL for data forensics, in a very ad hoc way. Edit: Now I use Calc and bash to write my bash ;)
- SmirkingRevenge 7y agoThere are less drastic ways to reduce SQL boilerplate, though - such as simple SQL dialect implementations, in your language of choice. I'd almost always prefer that kind of interface, when there's a decent one to use. Of course, your database may come with features that can help too (views, udfs, etc) I'd generally only reach for an ORM in one circumstance - when my team already knows it well, and can move fast with it. It should also be popular, so that its likely new team members already know it, and can move fast with it. Otherwise, you're just putting unnecessary obstacles in front of your team, in most cases.
- burpsnard 7y agoWhen-i-were-a-lad, it went SQL -> views -> stored procedures -> ProC