7 ms·

> 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 i

> 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.

miki123211 2y ago
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."
- somethingsome 2y ago
  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.
- petalmind 2y ago
  Ahh true, object oriented approach certainly helps making sense, and I assumed it by default. I'll think about that.
- Ekaros 2y ago
  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?
layer8 2y ago
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.

miki123211 2y ago

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."

somethingsome 2y ago
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.
petalmind 2y ago
Ahh true, object oriented approach certainly helps making sense, and I assumed it by default. I'll think about that.
Ekaros 2y ago
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?

layer8 2y ago

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.