Every developer faces this dilemma at some point: should I make my database smarter, or my code smarter?

When I first built my multilingual dictionary app, I started with a separate database table for each language pair: English-Turkmen, Russian-Turkmen, and so on. It seemed logical at first.

But soon, schema changes and data management became painful. Adding a new language felt like spinning up a new project each time.

So I went the other way. I normalized the database and moved complexity into the code.

Now the core dictionary function runs on three core tables: Word, Language, and Translation.

The result?

• The database became simpler and easier to maintain.
• The application logic became more sophisticated.
• The entire system became more scalable.

Interestingly, I noticed a similar design principle in WordPress: everything is a type of “post.” Pages, products, attachments — all unified under one flexible schema. With two main tables: wp_posts and wp_postmeta, WordPress achieves unlimited flexibility for content types.

The lesson? Complexity doesn’t disappear, it just moves.

There’s no perfect answer: just trade-offs that shift as your system grows.

In my case, keeping the database simple gave me more flexibility and consistency in the code.

What I find curious is that simplicity isn’t something you start with, it’s something you arrive at, usually after building things the hard way.