What are ORMs and When to Use Them

Check out the video for some more elaboration on the topics below.

If you liked it and want to know when I post more videos, be sure to subscribe

ORM Libraries

I'm about to do a few videos on a some Go ORM packages and thought it wouldn't hurt to do a dedicated segment on just talking about what ORMs are and why you should or shouldn't use them.

What does ORM stand for?

ORM stands for Object Relation Mapping. Typically this means communicating with a system using a language other than the native language is expects.

An example of this would be a SQL database. A SQL database is expecting, well, a SQL query to interact with it, but what if we wanted to interact with it with something like a Golang program?

What does an ORM do?

An ORM library gives us the mechanism by which to perform Object Relation Mapping. This means we end up with structs or classes that represent something like a table in our database

In golang, we would get something like this:

user := models.Users().ByID(1)

Which would generate the following SQL query:

SELECT * FROM Users WHERE id = 1;

Pros & Cons of ORMs

Pros:

• Much less time spent to interact with a database in your program
• Abstracts away the database being used, which makes it easier to swap to another backend
• If you have weak SQL skills, the generated queries are at least as good as if you wrote them, if not more performant.

Cons:

• If you need a very highly optimized query and you can write said query, it may perform better than the generated ones.
• There is some amount of mental overhead related to learning an ORM library
• Most ORMs require some amount of configuration
• May not help you developer stronger database and/or SQL skills

What kinds of ORM libraries exist?

From my experience, there are two primary types of ORM libaries

Code-First ORM

A code first ORM uses the code written or generated by the user to generate the database schema and applies the schema to the database.

Some examples of code first ORMs:

• Gorm (Go)
• Basically every ORM in most mainstream framework
  • Eloquent (Laravel)
  • ActiveRecord (RoR)
  • Whatever Django uses

Schema-First ORM

A schema first ORM reads the already defined schema from the database and generates from it, all the code necessary to interact with the database.

Some examples of schema first ORMs:

• SQLBoiler (Go)

When to choose which?

Code-First ORM

• Most ORM libraries in my experience are code first, so a lot of choices
• These tend to do alot, some code generation, acts as abstraction, and manages migrations (schema changes)

Schema First ORM

• Need to get up and running quickly with an existing database (legacy data)
• Almost ALL of the code will be generated, vs just some being boilerplated like most code first ORMs I've used
• You prefer a more unix approach, as most schema first ORMs I've seen don't handle migrations. You'll need to use a seperate tool or library to manage migrations.

Comments

[Vincent Milum Jr]

I'd just like to add some other points about ORMs.

They're handy for smaller, simpler projects, but there are other cons to them that are seldom, if ever discussed at all.

If multiple applications rely on a single database, then who owns the source of truth for the schema/model? Each ORM application instance can quickly become out of sync with one another.

Additionally, databases have added some absolutely AMAZING features in recent years that most ORMs have yet to really exploit. Document store (such as JSON data), spatial data, graph relationships, recursive queries, system versioned data, expanded data types, read/write sharding, clustering/high-availability/fail-over, and more.

For reference, I'm personally not against ORMs. Quite the opposite, having written a SQL query generator that also has ORM functionality for PHP. Through that development process though, I realized I always needed more and more functionality, and quite enjoyed exploring these more powerful features.

My main goal with this comment is that I just want readers to also know that ORMs, while an awesome tool, especially to get started right away, hide a lot of the really awesome things that databases can do these days. Please always keep exploring! :)

[Donald Feury]

Oh yeah, ORMs are by no means a silver bullet. Like you said, they are great for prototyping but they do tend to lag behind in making use of the more powerful and advanced features of most databases.

They also tend to primarily target SQL databases, its rare that I've found an ORM library for NoSQL databases like Mongo.

[Donald Feury]

Thank ya, appreciate the feedback.