How to use an Object Relational Mapper and never learn SQL
SQL is an old technology, and like most things from the 70s, it needs to be washed, possibly shaved, put up, forgotten, and hope it never comes back into style. But you see it everywhere, and some specialists seem to know everything about it and don’t permit you to work on it. You are at a big company, so there are DBAs, Data Engineering, Data Excellence, Data Operations, and Data Compliance teams, which all seem to use SQL to make you feel stupid or unworthy of access.
Data is messy and requires all this state. You need to install other software to manage it, and the data gets large and eats up disk space that could be used for other, better, things, like documentation, or Ghost Recon: Wildlands saved games. Something about data seems inelegant. You would prefer to operate on objects in memory; programming feels the purest in this form.
And if you are honest with yourself, you never really learned SQL, either in school or during training on the job. Sure, you can join some tables together and write some INSERT statements, and you know what a temp table is, but it just doesn’t feel like something you need to understand well. SQL scares you. There are teams of people who will handle any performance issue that arises from your code.
So you should focus on creating some performance issues and ignore it.
Pretending that something doesn’t exist is a classic move in software called abstraction or information hiding. If SQL and the relational model don’t exist, we can operate in our comfort zone and stay coding, not worrying about data integrity, data growth, schema upgrades, or compatibility. Just create a plain old object in your programming language and have it populate a string.
Hiding this "data" abstraction is easy - use an Object Relational Mapper (ORM). There are plenty to choose from for your favorite programming language. This is a (partial) list of ORMs for Golang:
Look at those cool names!
What’s that? You don’t hack Go but work in Typescript? The names there are also cool: Waterline, Mongoose, Typegoose, Bookshelf, Sequelize, Kenx.js, Bookshelf, TypeTyper.
C#? Well, OK, the names there are not as cool: DbConnector, DevExpress XPO, Entity Framework, LINQ to SQL, Dapper, Enterprise Data Compass.
Python? SQLAlchemy, Peewee, The Django ORM, PonyORM, SQLObject, TortoiseORM, CobraKai
Rust? You are cooler than everybody? diesel, quant, SeaORM, ormlite, SQLx, WD40.
Java? You aren’t cooler than anybody? Hibernate, jOOQ, EclipseLink, TopLink, Apache OpenJPA, CustomBeanMapperFactoryIsolatorAutoMapCartographer.
There are a lot of ORM libraries. Somebody should tell these ORM library writers to calm down. They get extra github stars for having “ORM” in the name.
Why are there so many? This must mean that they work well. If there are many things, then there is a market for them. I’m sure that the reason that people are constantly writing ORM solutions, and that a quick google search of any of these reveal a large number of posts of issues means that they are excellent. Wherever there is activity, there must be something good going on, right?
Paid subscribers view additional commentary about this post, with links to useful resources on this topic. If you are reading this and thinking, “well it depends,” or “this is a gross oversimplification,” or “what an idiot,” then you might be interested in Additional Commentary for this post.
ncG1vNJzZmiakZnAsLLTsJirnZGZw6qvxGeqrpqjqa6kt42cpqZnoGS1sMOMraZmraOaeqK6jKiZo52TqXqzscuaq6Knnpa5brnAqaeeqg%3D%3D