ORMs were never about not using or not knowing SQL. They are a convenience for people who already do.
If you don't know SQL, don't interact with an SQL database.
What ORMs have taught me: just learn SQL (2014)
131–140 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#132What happened to object databases? They seemed to have a brief moment in the spotlight during the 90s but haven't made much noise since. Bad product or just too much inertia with relational databases?
Re: What ORMs have taught me: just learn SQL (2014)
#133I've found that DDD and a read/write separation of concerns simplifies things greatly.
On the write side, the ORM just returns an aggregate, usually based on the PK of the root. Thats's trivial for any ORM.
On the read side, simple queries can be modelled with ORM syntax if you're just trying to fetch a graph of existing objects. Complex queries can be returned with raw SQL that map to custom read models. I tend to wrap both styles in integration tests that ensure the query logic doesn't change, and that the actual mappings don't break.
Both ORMs and SQL have their usages, and they're not mutually exclusive.
Re: What ORMs have taught me: just learn SQL (2014)
#134Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…
The best ORM (outside of ActiveRecord) I've seen was a proprietary hand-rolled one that solved the impedance mismatch.
It had a canonical XML format that entities were defined in and code generation for data access layers, domain models, view models etc.
It actually worked better than I've seen the abuse I've seen developers put EF through. I found it nicer and simpler than times I've worked with Hibernate.
I'm not going to say it was perfect, but every time I think back on it it makes me want to revisit the idea of leveraging a bit of code generation or metaprogramming to be able to have a canonical definition of an entity transformed into concerns that deal with the given entity at different points in the application.
That part of it just really hit the sweet spot for me.
Re: What ORMs have taught me: just learn SQL (2014)
#135Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…
Db4j is an async transactional database engine that uses java as the query language. It doesn't eliminate the O/R impedance mismatch entirely (it's not a graph or object database), but it does simplify it greatly since everything is java
I love the idea and it's been fun for me to make demos with, but I've gotten almost zero feedback on the API, and what I have gotten is "can you add a SQL frontend". And yet neither ORM nor SQL are loved
So the question (and I'm not suggesting that Db4j is the answer) is: "what's the API that would be most natural ?"
Re: What ORMs have taught me: just learn SQL (2014)
#136ORMs lure you in with a false sense of neat abstraction. They have nice intuitive examples on their home pages. But then you use them in the real world, doing gnarly queries, and you realize that doing anything powerful and fast in the ORM requires its own completely separate abstractions, which are often difficult for the uninitiated to follow. It's also often a big pain to debug the raw SQL that gets compiled after…
what else are you going to do? inline “SELECT” queries all over your code? Lots of PHP codebases look like that, I guess
Re: What ORMs have taught me: just learn SQL (2014)
#137ORMs lure you in with a false sense of neat abstraction. They have nice intuitive examples on their home pages. But then you use them in the real world, doing gnarly queries, and you realize that doing anything powerful and fast in the ORM requires its own completely separate abstractions, which are often difficult for the uninitiated to follow. It's also often a big pain to debug the raw SQL that gets compiled after…
[deleted]
Re: What ORMs have taught me: just learn SQL (2014)
#138Swapping from EF6 to Dapper was one of the best choices we ever made with our project stack. It is so relieving to be able to hand-tune queries and transactions now. Initially, we were sold on the apparent simplicity of EF6, but as with many things there is a cost for an abstraction like this. In our case, the performance penalties and opaqueness were dealbreakers after a while. We saw an average speedup of 10x on al…
I didn't quite understand fully how your solution worked in the end, are you storing the entire object graph as a JSON blob alongside the relational data in the table, or are you simply storing the JSON blob instead of using relational data? Its difficult for me to picture how Dapper even comes into play when you're doing this trick with the JSON blob. Why not use NoSQL? Also 1000+ properties on an object? I know som…
For certain abstractions, we are looking to maintain the state of a business process over time:
The relational concern is the storage of metadata sufficient to locate & retrieve the state. E.g.: integer primary key, name of process, current transition in process, some datetime info, active session id, last user, etc.
The 'non-relational' portion is simply a final 'Json' column per row that contains the actual serialized state. This state model can vary wildly depending on the particular process in play, so by having it serialized we can get a lot of reuse potential out of our solution.
In terms of the models, it's not 1 gigantic class with 1000 properties. Its more like a set of 100+ related models with 5-30 properties each.
Re: What ORMs have taught me: just learn SQL (2014)
#139An ORM is not a substitute for learning SQL. It's just a nice tool for more tightly integrating your database and your application code. An ORM can make you like much easier, but if you don't know SQL or how a relational database works, your ORM isn't going to save you.
Re: What ORMs have taught me: just learn SQL (2014)
#140Me thinks someone needs to have a go at maintaining a 2Mloc accounting package built using only embedded SQL statements and stored procedures, including migrating the whole mess between major database vendors. I guess one advantage is you have to learn, it but I really prefer some kind of ORM for more mundane repetitive CRUD. More to get a structured (ha!) interface between the database and the application than for t…
I deal with that. Millions of lines of SQL stored procs.
It's awful, but not anything an ORM could help with.