Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

woz.posthaven.com

Post reply on HN
Print view View original

291–300 of 360 posts

Re: What ORMs have taught me: just learn SQL (2014)

#291

Post by scarface74 »

zkomp wrote: post #284
scarface74 wrote: post #266

Earlier quoted context omitted.

And what's stopping you from having a tightly controlled interface with a REST Api that is easily deployed, rolled back, unit tested, source controlled and deployed?

I like data. A database is created to handle it, give you tools to query, modify, scale, secure the data. A rest api... how and why should it be responsible for your data? It solved a different problem. You might not even need a database I guess, and then anything goes. I need and like my database, and have suffered trying to get along with different ORMs. SQL is so good at what it is designed to do if you just let i…

One database is still an issue. When you have a clear slice with one microservice being in charge of one set of data, it's easier to scale, slice, rewrite, and you can deploy and iterate faster without interdependencies.

And you lose all of the benefits of microservices if there is still a tight coupling between unrelated (from a domain perspective) to tables.

Re: What ORMs have taught me: just learn SQL (2014)

#292

Post by scarface74 »

ZenoArrow wrote: post #286
scarface74 wrote: post #224

Earlier quoted context omitted.

If all of your business logic is in the stored procedures, what are you actually testing? And I realize that being able to test queries without database dependencies, only really applies to a few languages that treat queries as a first class citizen in the language like C# and Linq where you can mock out your actual Linq provider - replace the EF context with in memory List - and still test your Linq queries.

> "If all of your business logic is in the stored procedures, what are you actually testing?" Depends on what you want to test. Can either write unit tests for the stored procedures or unit tests for the code that makes use of those stored procedures.

And then when you write "unit tests" for stored procedures with a lot of developers you get slow "unit tests" that don't scale across multiple developers because of Comte toon issues.

Re: What ORMs have taught me: just learn SQL (2014)

#293

Post by sreque »

I really enjoy seeing this debate because I hope more anti-ORMers unite and we see less use of ORMs in future projects. There are other disadvantages of ORMs that I haven't seen mentioned much:

1) low-level performance. Even if, and it's big if, you manage to get your ORM to generate somewhere near the optimal query, ORMs in my experience are always significantly slower than hand-written sql. When I last benchmarked, I couldn't get hibernate to be any better than 4x as slow as JDBC, and keep in mind that's pure CPU overhead.

Think your service is I/O bound? It's probably not, and it's probably your ORM to blame. This may be less of an issue for a dynamic language like Python, but I see it as a much bigger issue for Java/C# and friends.

2) Debugging/understandability. Did you know that hibernate maintains a cache of every object you load in a session until you flush it? I didn't, until we had an outage because our service OOM'ed while loading too much data without flushing.

Do you know how exactly your ORM is loading and saving data and when? Depending on your use of the various lazy-loading and storing features of your ORM, it can be very difficult to reason about when and how your ORM is talking to your database.

Do you know how your ORM is integrating with your cache, which is likely memcached? Why is your ORM integrating into itself the concept of a cache in the first place? In my experience, hibernate gets caching wrong, and that's not entirely its fault. It's difficult to get caching right in the general case. But I would rather be forced to think about caching up front and get it right for my use case rather than try to understand how Hibernate is doing it and working around its mistakes and limitations.

The common theme is that the use of an ORM makes it incredibly more difficult to understand, reason about, and debug your application rather than using a simpler library. In my experience, this alone makes an ORM not pull its weight.

Re: What ORMs have taught me: just learn SQL (2014)

#294

Post by jdc0589 »

I have had exactly one positive experience with ORMs: nHibernate + fluent nHibernate config with .net's IQueryable expression interface. That is the ONLY time I have used an ORM and felt like I had enough control to do what I needed for edge cases and still the a perceived productivity boost; granted, there was what seemed like a large learning curve at the time. That said, I must prefer to just write queries myself and use an object mapper (Dapper, etc...) to eliminate a lot of the boilerplate.

Maybe there are some amazing ORMs for other stacks. But my time with .net was the only time I heavily utilized sql DBs.

Re: What ORMs have taught me: just learn SQL (2014)

#295

Post by huherto »

sreque wrote: post #293

I really enjoy seeing this debate because I hope more anti-ORMers unite and we see less use of ORMs in future projects. There are other disadvantages of ORMs that I haven't seen mentioned much: 1) low-level performance. Even if, and it's big if, you manage to get your ORM to generate somewhere near the optimal query, ORMs in my experience are always significantly slower than hand-written sql. When I last benchmarked,…

I kind of agree with you.

Using an ORM saves your from having to implement a lot of code. But you still have to understand how everything works. ORMs makes it look easy, but there is a lot of magic involved that you need to understand sooner or later.

Re: What ORMs have taught me: just learn SQL (2014)

#296

Post by randomdata »

exclusiv wrote: post #74
alexandercrohde wrote: post #61

Earlier quoted context omitted.

I think there are 3 main reasons ORMs came into common use: 1. As a reaction to common SQL injection from poor libraries not implementing parameterized queries. (2004 or so) 2. Novice engineers not wanting to learn SQL (look I learned how to make a blog in RoR, and I like mongo!) 3. As a theoretical abstraction above the data-store (as though you might someday be able to switch the data-store beneath the ORM) 1 has b…

I'd add #4 - it's just generally faster and more enjoyable to develop with a good ORM.

Although, I think what you plan to do with the data also makes a big difference. Which probably explains why opinions vary so widely.

For short-lived processes, like typical web applications and command line utilities – that load data from the database, do something with it, and then purge it from memory again – I'm becoming less and less convinced that ORMs are actually a benefit.

On the other hand, if your application plans to map the database data to memory for long periods of time, with the need to keep them in sync, then you're probably going to end up writing something that resembles an ORM anyway, and poorly at that. In this case a good ORM is beneficial.

Re: What ORMs have taught me: just learn SQL (2014)

#297

Post by keredson »

voodootrucker wrote: post #142
erikpukinskis wrote: post #79

Earlier quoted context omitted.

Ok, let’s break this down: > Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating query composition, providing abstraction for database-specific and driver-specific quirks None of that requires an ORM. A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. > providing patterns to map object graphs to…

It depends on how willing you are to allow your object graph to match your relational schema. The key is to let SQL be SQL. I wrote one that allows you to load data using standard SQL resource files, but it handles the persistence automatically: https://github.com/bgard6977/sqorm Flyway & jOOq take a similar approach: https://www.jooq.org/ Taking the SQL-first approach also allows you to serialize without circular re…

also https://github.com/keredson/DKO

Re: What ORMs have taught me: just learn SQL (2014)

#298

Post by mgkimsal »

scarface74 wrote: post #281
zaphar wrote: post #273

Earlier quoted context omitted.

"saved time" at the least optional time to save time. ORM's are a maintenance burden. They obfuscate DB performance behind usually an enormous API surface. Most software work is maintenance work. Optimizing for initial deployment is shortsighted.

What "enormous" API surface? It's not about "optimizing initial deployment". It's about "optimizing continuous deployment" and having "always releasable Software". I've worked for departments with 15 devs all working on the same codebase and we could release and rollback releases (A/B deployments) every week because we treated the database as a dumb data store. We had multiple branches at the same time, etc. I've als…

I like the idea of stored procedures. I get some of the value they bring. However, the few times I've been on projects where sprocs where the primary focus of logic/truth/app... it was always a pain.

* The 'developers' weren't allowed to write the sprocs. We were at the biz meetings, but the DB guys were hardly ever there - their meetings were separate for some reason, but because devs were at the meetings, the devs were the ones who also were the face of the project. When the project was behind, we caught it in the neck, even if we were bottlenecked waiting for the DB team to write their logic and expose it to us.

* The DB team was always fewer people, juggling more projects, and other things like system uptime, maintenance, backups, etc.

* The sprocs were never part of version control or part of any source code that we could ever see as part of normal development. They typically weren't subject to any unit testing process.

The answer to all of this is mostly human management, structuring resources differently, coming up with different processes, etc. But any of those things would have changed the power dynamic, which seemed to be the purposes in those environments. Hey, I can write a stored procedure too - let me write them, and if a DB wants to 'review' them - or really, anyone on the team - please review and let's hammer it out and make it better. But roadblocking projects until the DB guys can 'get around' to writing our mission critical procs is just silly.

One other 'weird' division I saw a few places was this "developers can never have access to production systems - that violates XYZ" (a regulation, or some 'law' that was never produced, etc). I asked what the core issue was, and it was "you can't just have developers going on to production and just making changes on live systems - that's ... (against our policy, etc)". This was particularly challenging in a situation where a critical bug only happened on one production system, and we weren't allowed to replicate the database to another system, nor was anyone with any knowledge of the deployed code allowed to get on to the production system to even see if what was deployed was what we'd developed. But... this was still "our problem". Yet... the DBA in this case was "allowed" to get on the system and hand-write new triggers and sprocs to 'fix' our problem, all without documenting/testing his code, nor committing the code to any repo for us to even have visibility in to the data manipulation he was doing to 'fix' the problem we supposedly cause but couldn't investigate.

Again, I know this isn't a problem specifically with stored procedures. When sprocs have been promoted as the primary interface, however, it's usually been a political/power grab more than a technical benefit. And yes, again, I know there are technical advantages in some cases, but usually not enough to outweigh the drawbacks I've encountered.

Re: What ORMs have taught me: just learn SQL (2014)

#299

Post by zkomp »

zkomp wrote: post #284
scarface74 wrote: post #266

Earlier quoted context omitted.

And what's stopping you from having a tightly controlled interface with a REST Api that is easily deployed, rolled back, unit tested, source controlled and deployed?

I like data. A database is created to handle it, give you tools to query, modify, scale, secure the data. A rest api... how and why should it be responsible for your data? It solved a different problem. You might not even need a database I guess, and then anything goes. I need and like my database, and have suffered trying to get along with different ORMs. SQL is so good at what it is designed to do if you just let i…

(have we come to some max nesting level here, cant reply to the child comment)

One db can be a problem, or a strenght depending on the domain; And I really dislike religious design, esp microservices.

I have less problems by avoiding ORMs (and religios microservice arch, or fundamentalist interpretations of rest)

Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either. It must be one system that guarantees concistency.

It works great, there is no downtime. The interfaces are defined, the database stands alone, updates are deployed separately.

Re: What ORMs have taught me: just learn SQL (2014)

#300

Post by huherto »

red_admiral wrote: post #226

My 0.02 BTC on the matter: Object-oriented programming 101 assumes that all your objects are in memory, in a graph, so you can do things like person.getFriends()get(0).getName() [assuming the person in question has >0 friends]. Each step in the graph is essentially a pointer dereference, costing a constant effort. (If your data is small enough to fit in memory, that's what you should generally be doing. People who us…

> Object-oriented programming 101 assumes that all your objects are in memory, in a graph,

Yes. We insist on using this OOP style where your objects are Person, Order, Invoice, etc. Ignoring that the data is stored in tables.

But, it may not be the only way. What if your objects really are things like Tables, Records and Relationships. (e.g PersonTable, OrderTable, OrderDetailTable, etc) and your operations are whatever you can do with these tables. We are trying to abstract away something that is very real. What if we embrace it instead ?

Post reply on HN