When I first entered the industry, ORMs were the thing. They were so much the thing that for the longest time I didn’t realize there were any other things to be had. We were taught you build a foundation for your project in the database and then you built everything else on top of that, and that was our lives, and everything was great.
Everything was great until your boss asked you to do a join across seventeen tables to get the current summation of an array of values and not only did your stored procedure look like a novel, but the performance was abysmal. The problem was, you were stuck. The system data had been specifically designed to meet the business needs at the time and to give a “future proof” way of arranging that data however we wanted via indexes, joins and views.
As Dr. McCoy would say, dammit Jim I’m a developer, not a psychic. It doesn’t matter how good you think you know your business or how well you think you know your data, trends change, requirements change, and your data had better keep up.
Long story short, ORMs work, as long as you can keep your systems siloed and you can have a large group of DBAs sitting around tuning, optimizing and backing them up, but what if you need to scale, and scale quickly?
Luckily, there’s a thing called the cloud, and all the cool kids are using it. Trouble there is, a developer has to move their mind out of the realm of ORM and into a more KVP type mentality. Switching to this mindset isn’t easy, it takes practice and discipline and a lot of frustration.
“We were told to build the foundation first”
I want you to build ONLY what you need.
“But how are we going to join the parent tables with the child tables?”
“Stop thinking like an ORM”
It was amazing to me how much of my thought process was built around that ORM model. I had been being suffocated for years, and unlike all the other technology suffocation that I was aware of, the ORM thing snuck up on me. I was a prolific badass when it came to database design. I could throw one up and have your system purring like a top without too much problem and I was hesitant to change.
Now, I can’t imagine going back.
Architecting a system based only on what is needed at any given point in time seems like a lesson in constant change.
“Won’t we always need CRUD operations?”
The truth is, we as developers build a lot of functionality based on the premise of “someday” instead of living in the moment.
Non-ORM thinking is different. We know what we need so we build what we need. If something else comes up, we build that. We cut our development time by tons, we are much more agile in terms of effecting change, and we can be far sexier in our persistence layers.
Business says, “hey, store this”
Persistence says, “whatever”
Business says, “hey, give me that thing”
Persistence says, “take it already, I don’t care”
Business never sees that under the covers we’ve taken three of the fields they’ve passed down and created a hashed composite key which we use to index in a KVP store so that when they ask for that data we can retrieve it quickly. 1 primary key, direct to the data.
This type of data structuring allows us to scale across a cloud environment where the idea of a “table” limits that capacity. There are a lot of different thoughts in terms of scaling in the cloud, but that is it’s own blog post. For our topic here, I will simply say that switching to a non-ORM model not long freed my mind, but it freed my data.