rbroth
commented
2 years ago Difficult.
-
We can pull out the excel formula for each row for the first year as a string. However, excel column letters aren't conserved when importing to postgres, so the frontend developer would have to still write the formula manually. That's what @andy-bevan has done for the postgres function. Difficulty: lots of work for the frontend guys. Also, we previously discounted hardcoding formulas in the frontend.
-
Pull out the excel formula for each year (add appropriate columns to the table e.g. year_0_value, year_0_formula), parse it somehow (perhaps with the software that @bgsandan demonstrated a while ago) and somehow convert that to frontend javascript. Difficulty: writing the code for pulling out the formulas and linking it to all the right values will be complicated and a lot of work.
bgsandan
267
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