Git as a NoSql Database (2016)

Re:Git as a NoSql Database (2016) by beagle3 on Tuesday April 06, 2021 @07:37AM (#26710639)

Iso8601 sorts just as well.

I saw no benefit in storing two copies. That’s recipe for problems - e.g. “update” code that doesn’t update both, or somehow updates them differently (which one is right?). You can probably have t-sql or some “check” constraint to enforce equivalence, but ... why?

For most practical uses, an ISO8601 textual representation is as good, though a little less space efficient.

[ Parent | on HN ]

Re:Git as a NoSql Database (2016) by dragonwriter on Tuesday April 06, 2021 @12:52PM (#26714230)

> Iso8601 sorts just as well.

No, it doesn’t, since all of the following are valid ISO 8601 representations of a date:

20210408 2021-04-07 2021-W14-1 2021W143 2021-097 2021098

(Now, consistently using any one of the ISO 8601 formats is sortable...)

[ Parent | on HN ]

Re:Git as a NoSql Database (2016) by beagle3 on Tuesday April 06, 2021 @05:45PM (#26717752)

Point taken.

I always recommend and use the specific ISO8601 format

    YYYY-MM-DDThh:mm:ss.sssZ

(or drop the ".sss" if not needed), and be 100% consistent about it.

But you are right, I shouldn't refer to this as "use ISO8601" because it is only one of the numeous possible formats described by that spec.

[ Parent | on HN ]