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
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.
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?
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;
- 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.
- 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
From my experience, there are two primary types of ORM libaries
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
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)
- 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.