Hacker News Reader

Comment by somethingsome | Hacker News Reader

>20 years ago, when I started with databases, I found natural to map a user object in my software with a unique 'user' table with many columns. (Excel style)

It's only when I discovered how things were implemented and the required space and combinatorial complexity that the 4NF started to make sense.

I think the natural 'naive' approach is to have many columns with redundant information inside.

At some point, with more experience, we see how this system is harder to maintain (burden on the code logic) and how much space is wasted. I discovered 4NF (without giving it a name) by myself to solve those issues.

The problem is that we teach 4NF to people that never implemented code with databases and had to solve the problems it generates if you only have multiple columns. So the examples seems artificial.

When for the first time I saw 4NF in my lectures, it was easy as I knew all the issues without.

View on HN

> I think the natural 'naive' approach is to have many columns with redundant information inside.

Interesting, thank you. I either don't remember that phase in my own learning, or I was lucky to read about the "correct" approach first. Maybe that's why I was so extra confused about 4NF explanations, haha.

I think it depends on what intuitions you start out with.

If you teach yourself programming as a kid like I have, and get to know about object-oriented programming very early on, normalization is more intuitive. "of course the addresses go in a separate table from the users, just as you'd have an `address` object instead of just putting all the fields inside `User`."

If you start out using Excel a lot, and learn programming much later, the Excel way probably seems right at first. "Of course there's going to be a table with customer information, one row per customer, with separate fields for street, city, zipcode etc."

Ahh true, object oriented approach certainly helps making sense, and I assumed it by default. I'll think about that.

You are right, now that I think about it, I was using php prior to their implementation of object oriented.

So I had no objects, the users were entities in my head, I had to keep track of their data, so a multi column entry in a database made totally sense to me at the time.

Also not stopping to think of further scenarios like shipping addresses. Like what if customer wants to store multiple addresses for shipping. How many of those they need? Is 10 enough? Do I now need street1 through street10?

If you maintain data records manually in Excel sheets, you tend to not “normalize” the data into several tables, because having to chase foreign-key references means you quickly lose track and don’t see everything related to a single entity in one place anymore. That’s because Excel doesn’t provide you with “joined” views. When inspecting a database interactively with a database GUI/TUI, this is very similar, unless you start building queries that lets you join the data together again (which is harder and less intuitive than just browsing tables and filtering/searching in them).

Of course, not normalizing the data makes it more laborious and error-prone to keep things consistent, the more non-1:1 data associations there are. When databases are not presented as an interactive table-browsing tool, but as an application’s data store, where the application can join data as needed, then the benefits of having everything related to an entity “in one place” (in a single table) are outweighed by the drawbacks of non-normalized data. However, this is not obvious when you start out in the table-browsing paradigm. People naively tend to structure the data the way they would for manual organization.

Reply on news.ycombinator.com