DEV Community: Itoro James

Databases, OLTP vs OLAP, and Normalization

Itoro James — Mon, 20 Jul 2026 19:19:44 +0000

Your contact list is a database

So is the sticky note where you jot down your shopping list. So is a shoebox full of receipts, if you're organized enough to sort them.

Database engineers might wince at that. But strip away the jargon, and a database is just this: an organized place to store data so it can be found again later. Scale it up, add rules, and hand control of it to specialized software, and you get what companies call a "real" database. That software is called a DBMS (Database Management System).

There are two broad families of databases:

Relational databases - data lives in neat tables with rows and columns, like a set of connected spreadsheets. Think MySQL, PostgreSQL. Data here follows strict rules about structure.
Non-relational databases - data doesn't have to follow a fixed table structure. It might be stored as flexible documents, key-value pairs, or graphs. Think MongoDB. Good for messier, less predictable data.
Neither is "better." They're tools for different jobs, and most companies use both, depending on what they're storing.

OLTP vs OLAP: same business, two different jobs
Databases don't just differ in structure. They differ in purpose.

OLTP (Online Transaction Processing) handles things happening right now, one at a time, fast.

Withdraw cash from an ATM and the system checks your balance, subtracts the amount, and confirms it instantly, correctly, every time. That's OLTP: small, frequent, real-time operations.

OLAP (Online Analytical Processing) handles looking back, scanning huge amounts of history to find a pattern.

"What was our average withdrawal across all branches last quarter?" isn't a question about one transaction. It's a question about millions of them. OLAP systems are built to chew through that kind of load, even if the answer takes a few seconds or minutes to arrive.

Picture a bank branch: OLTP is the cashier at the counter, serving one customer at a time. OLAP is the analyst upstairs, going through a year of receipts to spot a trend. Same building, same business, entirely different jobs which is why they need entirely different tools.

Normalization: fixing the copy-paste problem

Normalization lives on the OLTP side. It's a set of rules for organizing a relational database so a fact only lives in one place, and updating it doesn't turn into a scavenger hunt.

Take a messy table storing student enrollments:

Mr. Doe's email shows up twice. Change it tomorrow, and you have to find and update every row he appears in. Miss one, and now two different emails exist for the same person, and there will be the question of "which one is correct"?

Normalization fixes this by splitting the data into separate, linked tables:

Now Mr. Doe's email exists in exactly one place. Change it once, and every course linked to him is correct automatically. That's normalization: store each fact once, and link related facts instead of repeating them.

Why this matters more than it sounds
This is the invisible layer under every app you use. Your bank app shows the right balance because OLTP and normalization are quietly doing their job. A company's leadership sees an accurate quarterly report instead of five contradictory spreadsheets because OLAP is running on properly-structured data underneath.

Get this layer wrong, and every dashboard, report, and model built on top of it inherits the mess.

One-line takeaway: OLTP keeps the present accurate. OLAP makes sense of the past. Normalization is what keeps OLTP trustworthy enough for OLAP to rely on.

Data Engineering: The Data Field's Unknown Child

Itoro James — Sun, 12 Jul 2026 14:53:50 +0000

Why has nobody explained this to me before?

If you've spent any time around tech content, you've heard of Data Science. You've probably also heard of Data Analytics. Both have flashy job titles, viral LinkedIn posts, and "become a Data Scientist in 6 months" bootcamps aimed squarely at career switchers like me.

But somewhere behind both of them quietly, without the fanfare sits Data Engineering, and almost nobody talks about it.

That silence is exactly why I wanted to write about it first. Because once you understand what Data Engineering actually is, everything else in the data world makes a lot more sense.

So what is Data Engineering, actually?

In plain English: Data Engineers build the systems that move, clean, and store data so that other people can use it.

Think about a company like a food delivery app. Every order, every rider location ping, every rating that's raw data being generated constantly, from dozens of different sources, in messy, inconsistent formats.

A Data Engineer builds the pipelines that collect all of that raw data, clean it up, and store it somewhere usable.
A Data Analyst then queries that clean data to answer questions like "which city has the slowest delivery times?"
A Data Scientist builds models on top of that same clean data to predict things like "which riders are likely to churn next month?"

Notice the order. The Analyst and the Scientist can only do their jobs because the Engineer already did theirs. Without clean, reliable, well-organized data, a Data Scientist's fancy model is just guesswork dressed up in Python.

Why does it "sit" so quietly, then?

A few reasons, as far as I can tell:

It's infrastructure, not insight.
Data Science produces headlines "AI predicts X," "model achieves Y% accuracy." Data Engineering produces something less quotable: a pipeline that ran successfully at 2 AM without anyone noticing. Good infrastructure is invisible by design. Nobody writes a viral post about "the database didn't crash today."
It's less "sexy" in job-market marketing.
Bootcamps sell dreams, and "predict the future with machine learning" sells better than "learn to build reliable data pipelines." So the content ecosystem courses, influencers, breakdown videos naturally tilts toward Data Science and Analytics, even though Engineering is arguably the harder, more foundational skill.
You only notice it when it breaks.
Nobody thanks the Data Engineer when the dashboard loads instantly with accurate numbers. Everybody notices when the dashboard is broken, showing yesterday's data, or missing half the rows. Data Engineering's success is measured in the absence of complaints, which is a terrible way to build a reputation, but a great way to build a company.

The analogy that made it click for me

As a frontend developer, this is the comparison that finally made it land:

Data Engineers are the plumbers and electricians of a data-driven company.

When you turn on a tap and clean water comes out, you don't think about the reservoir, the treatment plant, the pipes, or the pressure systems that made that possible. You just expect water. The same is true of data, analysts and scientists just expect clean, available data to "be there" when they need it. Data Engineers are the ones who built and maintain the pipes.

Nobody builds a monument to the person who plumbed the building. But try running a city without them.

Why it actually matters

Here's the part that changed how I see this field: bad data engineering quietly poisons everything downstream.

If the pipeline that feeds a company's dashboards has a silent bug, say, it's double-counting orders from one region, every analyst report, every business decision, and every model trained on that data inherits the mistake. Nobody notices until a "insight" from that data turns out to be catastrophically wrong.

In other words: Data Science gets the credit, but Data Engineering is the thing that determines whether that credit was even earned.

Who needs Data Engineers the most?

Any company past the "spreadsheet stage." Once data is coming from more than 2-3 sources (app events, payments, third-party APIs, customer support tools), someone needs to be building pipelines to unify it or every team ends up with a different, slightly wrong version of "the numbers."
Companies investing in AI or ML. Every machine learning model is downstream of a data pipeline. Companies rushing to "add AI" without solid data engineering are building on sand.
Data Science and Analytics teams themselves. Ironically, the people who get the least public credit for Data Engineering are often the ones the Data Science team relies on most heavily, and complains about least publicly.
Regulated industries (finance, healthcare, insurance). Where data has to be traceable, auditable, and correct not just "roughly right" the engineering behind it is not optional, it's the whole game.

One-line takeaway: Data Science asks the questions. Data Engineering makes sure there's an honest answer to give.

This is post #1 in my public log of transitioning from frontend development into Data Engineering, starting with DataCamp's Associate Data Engineer in SQL track. Follow along as I break down what I'm learning, one concept at a time.

Contributing to a Browser Used by Millions - A personal experience

Itoro James — Thu, 16 Apr 2026 21:04:11 +0000

Choosing the Project

When I saw the Firefox project listed, I almost skipped it because it looked like one of the easiest projects, and I assumed it would attract the most people. My thinking was: if everyone is going there, maybe I shouldn’t.

But then a friend told me something:

“It’s not always about doing it. Sometimes it’s about doing it well.”

So I chose Firefox. And I told myself: don’t just do it, try to do it well.
Did I do it well? Honestly, I don’t know. I’ll probably ask my mentors for feedback.

Setting up the Codebase

Setting up the project was straightforward for me, but when I opened the codebase, I was honestly blown away.
Firefox is huge.

My first instinct was to understand as much of it as I could, at least the sidebar.
I initially tried to understand it details by details, i then realized that wasnt efficient, given time constraints, so i tried to understand the structure instead, how components were connected and the flow of things. With time i got a hang of it, and started to feel familiar, not simple, but familiar enough to navigate.

Ready to make my first contribution

Finding the first bug to contribute to wasn't easy at all, every bug i thought to be interesting already had multiple contributors indicating interest, or someone already submitting a patch, assigned or not. It felt like i was late to the party, the competition was real. In a bit not to be left behind, i submitted my first fix without being assigned the bug, it was a documentation fix, nothing technical, but at least i felt safe, i had made a contribution.

The Bug That Was Closed

My second contribution attempt hit differently:
Bug 1982519: No default icon shown when an extension icon is missing

Early on, I suspected the issue wasn’t really a bug, or had already been fixed. But I still went ahead and built a solution.

When I submitted it, Rob Wu from the Firefox extensions team questioned my use of a generic regex. After a few back-and-forth comments, things became clearer for both of us, and the bug was eventually marked out of scope and closed.

When I first saw his comment, imposter syndrome kicked in.
It doesn’t always announce itself loudly, it just shows up quietly and makes you feel like everyone else knows something you don’t.

I started questioning everything, was I wrong? Was my approach off?

But communication helped. We clarified things. I understood his perspective, and he understood mine.
That helped a lot.

The Bug That Almost Broke Me

My last bug turned into my longest week:
Bug 2015491: a keyboard navigation issue in Firefox’s tab notes feature

When a user navigates to the Cancel Button and presses Enter, the expected behavior is for the text box modal to close, and the note not saved. However, the note was still being saved.

I fixed it and submitted my patch. It was landed, then got reverted by the sherrif.
I fixed it again. Reverted.
Again, reverted.
Three backouts, three different failure messages.

That was tough.

The self-doubt crept in. The temptation to open ChatGPT got stronger. That quiet voice started asking: do you actually know what you’re doing?

But this bug became the highlight of my experience.

At one point, I found a “fix” something that made all the tests pass. Clean, green, Done.

I had already spent more time on this than I expected, part of me just wanted to submit it and move on.
But I knew that wasnt fixing the bug, it was just masking the problem.

I knew where the issue was, there was an existing test in browser_b_notes_telementry.js, that had a line of code there that didn't seem logically right, and was affecting my test, but as at the time i couldn't find the exact problem.

And that was the real test for me.
Not the code. Not the bug.
The choice.

Submit something that looks correct, or hold back and do what’s actually correct and better.

I could have submitted it, it probably would have landed, no one might have noticed.
But I chose to speak up and ask for help.

And I’m glad I did.
Not only did I fix the bug, I also helped identify and fix an issue in an existing test, something that wasn’t even reported as a bug yet.

In a way, I caught a future bug.

That’s something I’m genuinely proud of. Not because everything went smoothly, but because I chose integrity when it would have been easier not to.

The Rule That Made it Better

Firefox banned the use of AI tools during the contribution phase.
I decided to fully commit to that.
No AI-generated code. No AI explanations. Every bug, every fix, every mistake were all mine.

It wasn’t easy, there were moments I really wanted to open ChatGPT and just get unstuck quickly.
During this experience i realized something.
I had forgotten what it felt like to sit with a problem. To be confused and stay there for a while, to think through it without immediately reaching for a shortcut.

This experience led me to realize something, AI is an incredible tool, however, it is quietly weakening our ability to think (deeply) if we rely on it too much.

Working without it was uncomfortable at times, but the sense of total ownership at the end? That felt different, even better.

Conclusion

My code is now in Firefox 151.
Millions of users will benefit from a fix I wrote from my laptop in Abuja, Nigeria, without a single line of AI-generated code.

I made only two contributions to the Firefox project, if you exclude the out-of-scope one, just two.

But the experience, the growth, and the impact mean far more than the number.

I want to say a special thank you to Kelly, Nikki, Stephen, Rob, and Jeremy. I also want to say thank you to my fellow contributors, your blogs inspired me to put this out there.