3 ms·
> It's a constant fight between analyst and application developer. The analyst wants a history of all states. The application developer often only cares about h
by midev 9y ago
> It's a constant fight between analyst and application developer. The analyst wants a history of all states. The application developer often only cares about having a correct current state.
Again, this is totally and completely wrong. Actually, it doesn't even make sense, to say it's wrong. If I'm building an application to be used by an analyst, I want to hit all their requirements. They tell me what sort of data they want to be collected. If requirements change, or the data isn't as valuable as originally thought, or it's badly formatted, or whatever, then we work together to change it.
I don't fight with anyone.... They don't want shit data, and I don't want to store shit data. So who is there to fight with?
- xapata 9y agoThe case I'm considering isn't an application to be used by an analyst, but the analysis of an application used for some other purpose. It's often the case that an application only stores the current state. When there's historical data, it's often snapshots at regular intervals instead of an event log. Anyway, we're going way down a rabbit hole. All I wanted to say is that if the user, sensor, or application logic emits something weird, sometimes it's correct.
- Demiurge 9y agoAnd all everyone else is saying, constraint to all possible weird values and reject the junk. If you want free form text field, use that. Problem solved. Meanwhile numeric column is numeric only.
- xapata 9y agoI didn't hear it like that from the early comments, but instead encouragement to duplicate more complex logic from the application as database constraints.