micronutrientsupport / database-architecture

The Postgres database code for the MAPS tool
3 stars 0 forks source link

Intervention Costings Queries/Discussion Points #267

Closed bgsandan closed 1 year ago

bgsandan commented 2 years ago

@rbroth @andy-bevan - Feel free to 'upgrade' any of these to their own issues if/when appropriate

Having worked through the existing storage of the intervention costings data and looked at pulling it back out in various API routes for accessing and updating the data, I have come across a few things that I think need a little more thought, so I am documenting them here for now:

  1. intervention_data fields have no indication of their units/data types.   Would it be possible to include (in collaboration with @kpitten if spreadsheeet changes are needed), a field indicating basic data type (e.g. percentage, number, USD etc.) that could be used on the front-end for presentation?
  2. The field indicating whether values are totals / values etc. obviously gets used during import but is not reflected in the final data structure.  When returning all fields in a given heading tree e.g. "Start-up scale-up costs" -> "Training", there is no way for the API to indicate which fields are user updatable values e.g. "Number of training sessions" compared to calculated totals "Total training cost" without maintaining an exhaustive list of all possible permutations of row_name
  3. As previously discussed, although the database will be maintaining the 'canonical' values for various calculations (via @andy-bevan 's script), the front-end will need to do some calculations (e.g. , basic summing/multiplication of cell values, ensuring %age values sum to 100% etc.) within a given view when the user updates values.  What are your thoughts on the best way of encoding these requirements? Obviously the rows have a row_name e.g. total_inspections_cost = annual_factory_inspections x factory_inspections_unit_cost.  Should these relationships be stored in the db somewhere and returned to the front-end to parse, should the front-end 'know' these hardcoded somewhere, should it be something else - One for collaboration with the front-end guys here

There are also a few inconsistencies int the way that the spreadsheet values have been labelled (probably more for @kpitten):

kpitten commented 2 years ago

@bgsandan I looked at those inconsistencies and I think I must have caught/fixed them previously because I am not seeing them. I will share updated spreadsheets by the end of the day -- please let me know if they are still there or if there are other inconsistencies that you notice!

Also, @rbroth , let me know if I should add a separate column with data types (USD, number, percent, etc).

rbroth commented 2 years ago

@bgsandan please close this issue once you've checked that the inconsistencies are gone