Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If they "consider their input units to be part of the data", by which I assume you mean something like "if I use carbs here, and BU there, keep it that way", then you need to store the unit regardless. In that case, since value is always paired with a unit and both are variable, I totally agree. Encapsulate. Two related values that cannot meaningfully be separated should be treated as a single object.

But I've never seen a system like that for something like carb counting - it's always normalized, and everything is displayed in a single unit at a time, maybe changeable by user preference. Maybe the problem is that so far nobody has built such a system. Maybe it's that doing so means more complex SQL queries and larger indexes, because you need to consider two fields instead of one when summing / averaging / etc. Maybe it's because users don't want it.

The argument for ints in this case is also an argument that you should only show a single unit at a time. So long as that's true, the encapsulation argument carries a lot less weight - at that point, I'm not sure which I'd choose. The benefits are a lot less real, though.



In my case (astronomy) we have to store the units regardless and they're always together, but in light of changing requirements, I'm not sure it would be overkill to make this explicit up-front even if there weren't explicit requirements to do so.


Oh. You could have mentioned that. :P

Astronomy is the one field where it makes perfect sense to store the units, because basically nobody agrees on what the standard should be. My professor in college joked that if you had 5 astronomers in the room, you'd get 10 different sets of "standard" units.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: