Theoretically it's possible to imagine a normalised relation with 50 columns. In practice a table like that is unusual and suspect (frankly, even in a denormalised design).
That is impressively pointless pedantry even for HN, well done.
>Theoretically it's possible to imagine a normalised relation with 50 columns
Yes, that would be what I said. "You're wrong because exactly what you said is correct!"
Any linking of number of columns to normalization is pure nonsense. The only accurate thing that can be said is that if you split a relation into multiple projections, by definition each will have less attributes than the original relation. But this is a triviality and it says nothing about the number of columns in the projected relations.
Pedantry is though. And that's what that entirely pointless post was.
>Any linking of number of columns to normalization is pure nonsense.
That's what I said, that's the point. Don't jump in to a thread you can't be bothered to read.
A R-table is a visual shorthand for a relation -- a way to visualize it on some physical medium (paper, screen) and the two should not be confused.
Full normalization does not decompose into relations with same key, because that means splitting one type of entities in two, that makes no logical sense. Rather, it splits non-5NF relations that represent facts of multiple types into 5NF relations that represent facts of a single type and they have different keys.
sounds suspiciously like denormalization
Second, if they share the same key, then it's not normalization, as the the split relations have distinct keys.
Normalization is the process of organizing the attributes and relations to, among other things, eliminate redundancy. 2 relations that store and share the same primary key is by definition redundant.
Splitting relations for the sake of skinnier tables is creating redundancy(the primary key is stored twice) and insert/update anomalies and can be reasonably thought of as a denormalizing behavior.