4 ms·

This seems odd to me. This is basically just ways of finding database-esque tables in spreadsheets to then leverage for vector/matrix operations. It is a non-p

This seems odd to me. This is basically just ways of finding database-esque tables in spreadsheets to then leverage for vector/matrix operations. It is a non-problem for anyone who really cares about performance as they've probably already realised they can just use a database some efficiently programmed transformations. I guess it would be a great help for those poorly-optimised mega-spreadsheets that one can find in the corporate world. I'd say that the solution shouldn't be a smart algorithm to enable further mis-use of excel/spreadsheeting-tools, but rather to migrate the processes to a database. Not only do you get better data storage and computational speed efficiency, you also enable better data governance and access (or access control). This paper is like adding an extra lane on a highway and making traffic worse.

BenoitP 4y ago
> the solution shouldn't be a smart algorithm to enable further mis-use of excel/spreadsheeting-tools, but rather to migrate the processes to a database In an ideal world only. Being able to have intricate computation definition being user-modifiable is a big feature. I have successfully 'appified' such Excel sheets in the past, only to be recognized as the new business rule maintenance guy. I no longer do that anymore: I identify moving parts, and these stay in the Excel world instead of going into the DB or a config file. I do clean the inputs and harden access control though. The apps are quite often low traffic so this setup might cost at most 100 USD/y in wasted performance per app. Nobody tracks that anyway. The business guys are happy to maintain the thing, I'm happy they're not bothering me. What is not so good is the latency of some queries. IMHO Excel is a great global minimum in the 'Configuration Complexity Clock' [1]. Or maybe I just don't care enough anymore. [1] http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...

BenoitP 4y ago

> the solution shouldn't be a smart algorithm to enable further mis-use of excel/spreadsheeting-tools, but rather to migrate the processes to a database In an ideal world only. Being able to have intricate computation definition being user-modifiable is a big feature. I have successfully 'appified' such Excel sheets in the past, only to be recognized as the new business rule maintenance guy. I no longer do that anymore: I identify moving parts, and these stay in the Excel world instead of going into the DB or a config file. I do clean the inputs and harden access control though. The apps are quite often low traffic so this setup might cost at most 100 USD/y in wasted performance per app. Nobody tracks that anyway. The business guys are happy to maintain the thing, I'm happy they're not bothering me. What is not so good is the latency of some queries. IMHO Excel is a great global minimum in the 'Configuration Complexity Clock' [1]. Or maybe I just don't care enough anymore. [1] http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...