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

You might as well timestamp it

changelog.com

Post reply on HN
Print view View original

111–120 of 205 posts

Re: You might as well timestamp it

#111

Post by hk1337 »

traceroute66 wrote: post #82
antender wrote: post #68

Also, from the point of query optimisation this is a really bad idea. Usually you DO actually care about size of fields in SQL databases, because something like BOOLEAN is usually stored as single byte (or bit in a bitfield) vs 4 bytes or even 8 in case of timestamp. This not only multiplies on disk usage by at least 4 times, but also makes ALL indexes using this field way bigger. Also boolean indexes can be compress…

> This is also the reason why serial IDs are way better than UUIDs for internal IDs. There are three core problems with that: a) Serial IDs are a nightmare for database merges, clustering or anything like that b) Serial IDs won't scale c) Serial IDs require management, whilst UUIDs can be produced anywhere (in DB, in frontend etc) There is the KSUID[1] if people want a time-sortable thing that is near-enough to a UUI…

You can do both. Use the UUIDs where you need the scalability and serial where you don’t.

Re: You might as well timestamp it

#112

Post by forkerenok »

isuckatcoding wrote: post #109
forkerenok wrote: post #92

Earlier quoted context omitted.

I think this is still workable with an expression/functional index, where the indexed expression is "happened_at IS NOT NULL".

Seems like a whole lot of extra trouble to be honest. What happens when you need to create a composite index?

You can do indexes that are composites of plain field values and/or expressions! At least in Postgres.

As for the trouble, I agree, it's a bit more involved.

Re: You might as well timestamp it

#113

Post by ximm »

imperistan wrote: post #72
ximm wrote: post #43

One important downside: Data protection. This approach of "store it now in case you might need it later" is in direct violation of the principle of data minimisation in GDPR.

I think thats only the case when it the data can be used to (help) identify a specific person

No, not exactly. It is the case when this data is related to a single person. E.g. "has this person subscribed to my newsletter" vs "whan has this person subscribed to my newsletter".

Re: You might as well timestamp it

#114

Post by isbvhodnvemrwvn »

tuukkah wrote: post #59
timzaman wrote: post #46

Earlier quoted context omitted.

"triple state boolean", what's next, a double precision fp32?

Also known as *bool, "Maybe Bool", "Boolean?", "Optional " etc.

Well, in browsers there's `HTMLMediaElement.canPlayType()` which returns one of the following strings:

- "probably"

- "maybe"

- ""

Reference: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaEl...

Re: You might as well timestamp it

#115

Post by aasasd »

I have about the same sentiment in regard to personal notekeeping, and do in general care about preserving metadata. Many times I have consulted the date when I created a note or, say, an entry in the password manager—or when I last changed it. That may inform my decision on what to do with the note next, or at least allows me to contemplate how much is not done in the passing years and how much is yet to not do.

‘Remember The Milk’ and Evernote make it pretty nice and easy by keeping the dates and some other info. (Though of course there's a gotcha that RTM's Android app forgets to implement the display of this metadata.) Not that I recommend these apps currently, especially Evernote.

Well, after migrating to Org-mode I have a persistent itch caused by the fact that Org doesn't have modification times for outline items, and implementing them in Emacs is a pain. That's one downside of not separating the view from the model. But the creation time is easy to add, in case someone wonders.

Similarly, I love having the archive of deleted notes and completed todos: once in a while I need to figure out what the hell I did to some particular items, or I change my mind on some edits. And on bulk moving or copying, I like to keep record of what I moved from where. (cough unlike HN ahem.)

Re: You might as well timestamp it

#117

Post by MayeulC »

antender wrote: post #68

Also, from the point of query optimisation this is a really bad idea. Usually you DO actually care about size of fields in SQL databases, because something like BOOLEAN is usually stored as single byte (or bit in a bitfield) vs 4 bytes or even 8 in case of timestamp. This not only multiplies on disk usage by at least 4 times, but also makes ALL indexes using this field way bigger. Also boolean indexes can be compress…

Theoretically, this should compress quite well. In practice, I don't know how much compression db engines apply.

Re: You might as well timestamp it

#118

Post by berkes »

kown7 wrote: post #58

In this case, why not go straight to append-only databases where every entry has a timestamp? That will be _the_ audit log in your database.

This was my thought too.

Timestamps are a usefull trick. But also one that allows you to postpone what the domain is really asking: to store a log of events.

Maybe even as primary source (aka event sourced).

Re: You might as well timestamp it

#119

Post by LaGrange »

bob1029 wrote: post #64
LaGrange wrote: post #56

Earlier quoted context omitted.

> are not interested in a 100% authentic modeling of the problem A model is an approximation. There is no such thing as "100% authentic modeling" for anything non-trivial, and insisting on it grows models that aren't particularly useful. They might _seem_ simple at first glance because of their "purity", but a) they're not _actually 100% accurate, and b) are usually very fragile on revision, becoming, ironically, qui…

A model turns into a gamble if you throw your hands up and claim that its impossible to have a 100% authentic model of a domain. If you truly believe this to be the case, then you have not tread far enough into the forest of SQL, 3NF, BCNF, and the relational calculus. It is possible to use math to prove that a problem domain is modeled appropriately. With SQL and views, you can construct extremely high-order represe…

> A model turns into a gamble if you throw your hands up and claim that its impossible to have a 100% authentic model of a domain.

...no it doesn't. I've deleted the claim that you don't know what a model is from the previous comment, but now it's clear: you don't know what a model is.

> If you truly believe this to be the case, then you have not tread far enough into the forest of SQL, 3NF, BCNF, and the relational calculus.

...you're mixing models with mathematical theories in there, and none of these are "100% authentic models" of anything. Unless by authentic you mean "not copied", I suppose.

> It is possible to use math to prove that a problem domain is modeled appropriately.

...appropriately doesn't mean 100% accurate (which is _I think_ the word you were looking for). That's not how models work.

> The only way any of this becomes possible is if you have solid foundations and the courage to produce exceptionally clean models.

"Clean" doesn't imply "accurate" at all. It does sometimes help with being useful or easy to implement, but it usually _sacrifices_ accuracy. Like the two main and often contrary properties of models are "accuracy" and "usefulness." That's, like, first five pages of any epistemology handbook.

> You can do this shit in excel.

If you start in excel, you ain't getting anywhere. And this is not, by the way, a dunk on Excel.

Re: You might as well timestamp it

#120

Post by Supermancho »

cdirkx wrote: post #86
davidverhasselt wrote: post #23

There is a downside which I've experienced: if you want a triple-state boolean (null, false, true) then having a boolean column allows for that while a timestamp-as-boolean column does not (you lose the "null" value because that equals `false` in timestamp-as-boolean). Having a distinction between `null` and `false` can be handy for values that are optional or have a dynamic default. If it's `null` you know it is not…

The obvious solution is to encode it like this: `null` is `null, `yes` is the timestamp when it was set and `false` is a timestamp somewhere in the future. Now t You just have to pick your `false` timestamp somewhere far into the future, let's say something arbitrary like 03:14:07 on Tuesday, 19 January 2038. The software won't be around for that long anyway, so it will never be a problem...

Store your timestamps in a long int or string.

Positive = timestamp

-1 = false

0 = null

Post reply on HN