Frangible
commented
9 years ago Currently there is no concept of tubes in the database or API, only manufacturer and device, which are non-relational strings.
Implementing this requires relatively significant changes to the data structures which may be beyond the scope of the current API; in short, devices would need to be conceptually extended to have concepts about sensors / data channels, and a formal relationship between raw sensor data (CPM, etc) and SI or derived SI units would need to be defined.
This also brings into question of whether or not it should be the API's (or other downstream applications') responsibility to transform raw sensor values into a SI or derived SI unit or not. For example, consider air quality sensors, for which data cannot be transformed into a derived SI measurement by a simple static factor, and relies on multiple non-linear variable constants such as temperature.
Storing data primary as raw sensor values thus increases the complexity of all downstream applications of the data to a degree with more complex sensors that is detrimental to the use of the data. (eg, non-linear temperature calibration) It potentially makes re-use of the data almost impossible if how to arrive at the final derived SI unit is not contained in the source data.
I would recommend this (and other issues) in a future API revision be resolved through data structures that more precisely define devices and sensors, and by storing measurements only in SI or derived SI units such as uSv/h, with the raw sensor source data available as a secondary source.
Another alternative would be storing raw sensor values as measurements (as is done now) but with relationships that allow the final derived SI measurements to be automatically calculated from the input -- which is along the lines of your original suggestion. The issue with this is that it increases the data storage requirements, complexity, etc as again, non-Geiger counter conversion is tricksy.
tl;dr:
- Device(s) -> Sensor(s) -> Channel(s)
- Derived SI measurements only or data structures that define raw -> derived SI
- There is no room for varchar weakness in database normalization Sparta
If we could implement a drop down menu for the tube selection the fixed sensors would be much easier to do the cpm-uSv/h conversion. Tube chooises could be done by the admins.
rob