Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

6NF File Format

habr.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: 6NF File Format

#21

Post by rixed »

hdjrudni wrote: post #19
rixed wrote: post #18

> country_code 01K3Y07Z94DGJWVMB0JG4YSDBV A 7th normal form should mandate that no identifiers should ever be assigned to identifiers.

Not sure about that. Some folks would argue you should always use surrogate keys. I probably wouldn't for country_code specifically, but for most things its useful even when you have a 'natural' key.

It can be useful in some cases but can also be a hindrance. First because identifiers are more useful when they allow to actualy identify the thing; and also because now they can change from instance to instance, from customer to customer etc...

Re: 6NF File Format

#22

Post by throw-the-towel »

wearable wrote: post #11
balamatom wrote: post #5

Earlier quoted context omitted.

habr is an institution. it's like the "runet hn", minus wild west vc ecosystem, plus integrated blog posting like lj ogs intended to. probably helps a lot with original work like TFA getting traction. more power to that! runet sites of that era are often born out of the hacker's characteristic contrarian attitude "because we can". attempts to monetize them in more recent years are bound to accomplish little more than…

What are the modern equivalents of habr?

There's probably none. The Russian Internet has been Eternal Septembered too much for something similar to appear.

Re: 6NF File Format

#23

Post by snthpy »

sergeyprokhoren wrote: post #20
inkyoto wrote: post #14

Earlier quoted context omitted.

I would say it is a niche solution that solves a specific problem. Modern data sources increasingly lean towards and produce nested and deeply nested semi-structured datasets (i.e. JSON) that are heavily denormalised and rely on organisation-wide entity ID's rather than system-generated referential integrity ID's (PK and FK ID's). That is a reason why modern data warehouse products (e.g. Redshift) have added extensiv…

This is a fairly common problem. Data is often transferred between information systems in denormalized form (tables with hundreds of columns - attributes). In the data warehouse, they are normalized (data duplication in tables is excluded by using references to reference tables) to make it easier to perform complex analytical queries to the data. Usually, they are normalized to 3NF and very rarely to 6NF, since there…

Nice. Anchor Modelling is underappreciated.

Gonna have a look at your DSL.

Re: 6NF File Format

#24

Post by sergeyprokhoren »

unquietwiki wrote: post #7

Looks interesting, but few comments on the forum & even a negative vote count ATM. Format kinda looks "old school" in terms of defining records, but I guess that can be a positive in some circumstances?

What does looks "old school" mean? Do you want to wrap this format in JSON like JSON-LD? I don't mind

Re: 6NF File Format

#25

Post by adammarples »

deepsun wrote: post #10

Improvement idea -- in my experience "valid_from" is always a date (no time, no timezone). That's how it's reported in documents (e.g. contract validity period). Rows that need seconds (e.g. bank transactions) are events, they aren't "valid" from a particular point in time forward, they just happen.

No point losing information like that. What do you do if someone opens and closes an account on the same day? Changes their email address three times in one day? Etc

Re: 6NF File Format

#26

Post by deepsun »

adammarples wrote: post #25
deepsun wrote: post #10

Improvement idea -- in my experience "valid_from" is always a date (no time, no timezone). That's how it's reported in documents (e.g. contract validity period). Rows that need seconds (e.g. bank transactions) are events, they aren't "valid" from a particular point in time forward, they just happen.

No point losing information like that. What do you do if someone opens and closes an account on the same day? Changes their email address three times in one day? Etc

Agree, if your updates have time then datetime it should be. It's just in my work everything is date only. E.g. employment starts on a date, not datetime, there's no data loss.

Re: 6NF File Format

#27

Post by balamatom »

throw-the-towel wrote: post #22
wearable wrote: post #11

Earlier quoted context omitted.

What are the modern equivalents of habr?

There's probably none. The Russian Internet has been Eternal Septembered too much for something similar to appear.

if i knew any, i sure as fuck wouldn't post them on hn of all places.

Re: 6NF File Format

#28

Post by gregw2 »

sergeyprokhoren wrote: post #20
inkyoto wrote: post #14

Earlier quoted context omitted.

I would say it is a niche solution that solves a specific problem. Modern data sources increasingly lean towards and produce nested and deeply nested semi-structured datasets (i.e. JSON) that are heavily denormalised and rely on organisation-wide entity ID's rather than system-generated referential integrity ID's (PK and FK ID's). That is a reason why modern data warehouse products (e.g. Redshift) have added extensiv…

This is a fairly common problem. Data is often transferred between information systems in denormalized form (tables with hundreds of columns - attributes). In the data warehouse, they are normalized (data duplication in tables is excluded by using references to reference tables) to make it easier to perform complex analytical queries to the data. Usually, they are normalized to 3NF and very rarely to 6NF, since there…

Cool to see you tackle this problem.

If I were you though, I'd consider if I'd get more traction with an open source extension of Iceberg format that supports row based reporting and indexes for a unified open source HTAP ecosystem.

Post reply on HN