Hacker News Reader

Comment by emmelaich | Hacker News Reader

Excellent article. 1NF is part of the problem as the article mentions.

I'm seen some articles say that atomic in 1NF means you cannot have things that can be decomposed. All that matters is that you can perform the relational algebra on the table and get a sensible result.

To the why of presenting normalisation from those wacky forms, I think that also comes from data ingestion. You'll get a list of attributes for an employee from their CV and might naively just load that 'as is' into a table.

View on HN

> you cannot have things that can be decomposed.

Indeed. You couldn’t store integers because those are decomposable into bits.

Atomicity was always a BS concept, and Chris Date and Hugh Darwen themselves have written as much on this topic. It didn’t help that although Edgar Codd had a math background, a lot of things published on the relational model just didn’t have formal rigor, but people interpreted it as such.

haha, I don't want to express disrespect to The Ancients, but I'm bewildered at the entire 3NF/BCNF thing, couldn't they just patch 3NF already by including the BCNF fix? Why do we need to bother with "3NF-but-not-BCNF" as a separate concept?

> a lot of things published on the relational model just didn’t have formal rigor, but people interpreted it as such.

I wonder if you may have something that substantiates this claim? I agree that relational theory doesn't look very complicated in principle, and it doesn't seem to be very "productive" as a theory. Compared to group theory, for example.

Technically you're storing the order of the bits, which isn't decomposable.

Well without atomicity you can't have 1NF, and thus none of the latter. So let's hope you never store a content of a text content of a configuration or log.

I don't understand that comment. What do you mean "let's hope" if I can easily store a text content of configuration or log into a column?

I believe it's a joke. However ... if you store a CV as a blob then separately store skills, experiences in a different table --- does that make the db design imperfect?

Ah, okay.

Yeah, I was thinking about the way how to actually build a non-1NF database. So far my best idea is to store sqlite files as blobs in a different database.

Even that is 1NF, probably. As long as you don't have the id,blob duplicated in a table.

1NF (depending on the definition) has a few subtleties that make it either impossible to avoid in any relational database or almost impossible to enforce!

By impossible to avoid, I mean the basic rectangular shape of a table.

By impossible to enforce, I mean the avoidance of duplicates (without indexes) and NULLs.

Thank you!

> I'm seen some articles say that atomic in 1NF means you cannot have things that can be decomposed.

Yeah, this seems to be an vague argument, but it's not clear what it means. If I write "WHERE name LIKE 'A%'", does it mean that I "decompose" the string?

I don't see a difference between that and "where the column with array of languages contains string 'fr'".

My goto example is phone numbers; typically you store the whole thing, but what if you want to do analysis on zones? You'd just extract the zone, not redesign your schema and rebuild the database.

You could argue that things like LIKE and SUBSTR etc are not really part of the relational model at all, but merely application code leaking into the SQL for convenience.

Therefore, you shouldn't expect / demand that the results are a formal relation.

Reply on news.ycombinator.com