Hi,
The value attribute is set as character in the table measure. Why not as numeric? Having value as character is far than simple to handle in term of data management. I can foresee circumstances when character might be needed as for example a positive/negative result but in such a case it can be replaced respectively by 1/0 with unit mentioning it is reported as a positive/negative result. Let’s imagine a scale results from super hard/hard/fairly easy/easy. Again it can be replaced by a scale respectively from 4 to 1. What do you think?
Thanks for your reply.
Hello! Thank you for this point and for this question, and I take your point well. Apologies that it’s taken me so long to respond to it.
The idea for having the value field data type as varchar was too allow as many kinds of data inputs as possible. Ranging for numeric (the most popular) but also categorical inputs as all. To you point on the true or false/1 or 0, and likert-scale like responses, I think that’s also reasonable.
The issue arises for items that record characteristics, usually for sites. Measures like weather, or sample characteristics, which have values like “sunny”, “rainy”, “cloudy”, etc. Technically in the sets table these values now have enumerations, so they could be referenced as numeric if need be. The reason we’ve left it as varchar though is to facilitate ease of input, though I take your point again about the complications it causes for analysis.
I suppose my question back to you is: do you find that the varchar data type is enough of a problem for analysis that you would prefer to use the sets table enumeration key for all character values? And even at the input stage?
Thank you for your feedback and suggestion!
Hello @wastewater_belgium – just wanted to follow up on this to see if you’re able to give a little more context in line with my above comment. Thank you so much!