Live data from Hacker News

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

wozniak.ca

101–110 of 654 posts

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

#101

Earlier quoted context omitted.

ORMs make the simple things simple, and the complicated things impossible.

ORMs let you drop into SQL whenever you need, usually in a way that is fully compatible with the model, so that's entirely false.

Running raw user SQL isn't a prerequisite of an ORM needed to make it an "ORM", it's a useful feature that most ORMs try to include because the authors recognize the many shortcomings. Also, by writing raw engine-specific SQL, you automatically invalidate one of ORMs biggest selling points which is being SQL-database agnostic.

And by "drop into", this typically means writing custom stitching code that stitches the SQL cursor results back into the models again. It's rarely straightforward.

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

#102
This article was well balanced. I find title just a bit misleading, since "What ORMs have taught me: just learn SQL", to me, carries a slightly different message than "What ORMs have taught me: learn SQL".

The second sentence is a little more compatible with the first line, "they can be used to nicely augment working with SQL in a program, but they should not replace it."

That's certainly how I use them. ORMs can save you a lot of irritating typing where it comes to insert and update statements. Aside from that, I write a lot of raw SQL.

I have seen what I would describe as ORM-induced, yaml-induced database damage. This isn't meant as a criticism of these tools per se, they're perfectly compatible with a well designed app. But I have noticed that people sometimes create databases that are useful only in the context of their configuration-file/ORM heavy app. Essentially, the programmers conceive of their data as a set of objects, and they use the config file to store global constants and the ORM to persist files, almost as if they're pickling and retrieving objects back into the system.

The result is a database that can't really be queried with SQL, more or less useless outside the context of the application. I firmly agree with developers who maintain that information will outlive an application, a database will outlive the software that was originally designed to use it (perhaps in parallel with it). I think a SQL database should be useful all on its own as a data source. If you got rid of the app, you'd lose a lot of operations on that data, a lot of UI, a lot of valuable things, but you'd be able to get at and use your data. If that's not the case, I'd seriously reconsider the design.

Kind of hard to do that without understanding SQL, so yeah, definitely learn it.

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

#103
post #51

Swapping 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 some domains sometimes surface these kind of extreme cases, but is there not an alternative to having 1000 properties in one object?

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

#104

Code thinks in objects and functions and values and pointers. Databases think in tables and columns and rows and queries and indexes. If you don't pick an ORM to help manage this translation layer, then you'll end up re-implementing your own. Maybe this is OK, because yours will be simpler for quite some time. What else are you going to do? Stored procedures? Concatenated strings?

> If you don't pick an ORM to help manage this translation layer, then you'll end up re-implementing your own.

Only in the loose sense that you have to put the data into an object. That's a tiny portion of what most ORMs actually do.

I just cloned the hibernate-orm repo and, even excluding the .git files and /test/ directories, it has about 30 MB of source. There's a lot in there.

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

#105
post #32

Earlier quoted context omitted.

If the argument is that it's the right tool for simple jobs, then by definition it won't save a lot of effort.

That's not true. A simple job might be 3 lines of code in an ORM to update a record. In SQL that will be a lot more code especially if that's wiring up a foreign relationships. With SQL you will also have a lot of uncheckable strings containing code. Simple tasks are done maybe thousands of times in any one application. It's the complex tasks are rare.

> With SQL you will also have a lot of uncheckable strings containing code.

A good SQL access library can validate queries against the database itself at build time.

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

#107
post #97

Earlier quoted context omitted.

I am seriously glad I don't work on this project!

Care to elaborate on which aspect noted above is adverse from your perspective? I would be happy to provide more context and explain in more detail some of the reasoning involved in our decisions.

> Deserializing a JSON blob to/from a column into/from a model containing 1000+ properties in complex nested hierarchies

> complex, rapidly-shifting business models

Your business logic classes have 1000+ properties. And you plan to not migrate them when the schema changes but leave many instances with old versions of the schema sitting in the datastore. Your application logic is going to get nasty!

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

#108
post #95

What are some good rule-of-thumbs for when to use ORM vs SQL? I have worked with SQLAlchemy and Entity Framework, before and like them, but haven’t been able to find that magical demarcation line for when to go raw SQL. Does anyone have basic rules they use for determining this? Applicable to MVP or enterprise level products

The more joins or when you need more performance, drop into SQL.

SQLAlchemy's expression language is a good middle ground. I will start there if I need to do more than a couple of joins.

As some people have noted here, I think the biggest problem is that people who only know ORMs will have trouble because their understanding of the database will be limited by their lack of SQL knowledge.

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

#109
post #71

Surprised to see no one has mentioned query builders (like http://knexjs.org - no affiliation). All the niceties of not writing raw queries but no abstraction leaks... Although I have found for anything more interesting (recursive queries, etc) there is no escaping raw queries and every developer needs to bite the bullet and learn SQL.

I see query builders as a learning tool for fresh developers, and as a job aid for business analysts. For some this can be the final destination, but for any developer I would push hard to get them writing SQL by hand ASAP.

A few weeks of suffering through DIY SQL is really the only way to fundamentally understand how the database is working for (or against) you. Once you learn it, it really does become like a second language. You can fade in and out of proficiency based on recency of exposure, but it is mostly like riding a bicycle. One other advantage is you can take it across any SQL platform without a second thought. Many ORMs have provider-specific compatibility woes to contend with.

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

#110
I used ORMs JPA/Hibernate in several projects/teams and the outcome is always the same: things always get messy and overcomplicated, few reasons :

- they push developers to design super-normalized db schemas that look beautiful on paper but are horrible in practice

- the average developer has a very superficial knowledge of how ORMs work and this often leads to bad code/performance

- soon or later you will find yourself fighting the "framework" because what you are trying to do does not fit their model (e.g: upsert)

In my experience, this whole idea of abstracting from the DB is faulty at its root. You want your code to be close to the DB so that you can use all the greatest and latest functionalities without waiting for the framework X to support it.

I have found that JOOQ or simply Spring JdbcTemplate in most cases are more than enough.

Post reply on HN