I am well aware of ODBC. Critically you cannot edit the database itself, only copy from it. This makes sense so as not to let some sales guy tank an entire company becuase he misspelled a formula. What I mean is a spreadsheet that literally runs on a database. It could even be sqlite, _anything_ that allows two way communication between the slreadsheet and the application.
spreadsheet gui <--> database <--> application
The spreadsheet does simple data manipulation and acts as a GUI
The database can be mysql, postgres, sqlite (even JSON...)
The application does batch processing, generates documents, sends emails ect. everything excel can't or shouldn't do.
This stack could solve, in my opinion, >50% of all business software.
I have also considered some sort of general data storage but it's too slow. Drop box et al are not made for anything close to real time communication, which is critical for a spreadsheet that needs to talk to a program. Something like 100ms at most. This would also presumably require a perfect .xlsx implementation to read and edit the data which doesn't exist to my knowledge.
Google sheets, maybe excel, can make http post and get requests. It’s trivial to write an api that can read/write to a database on behalf of the spreadsheet.
spreadsheet gui <--> database <--> application
The spreadsheet does simple data manipulation and acts as a GUI
The database can be mysql, postgres, sqlite (even JSON...)
The application does batch processing, generates documents, sends emails ect. everything excel can't or shouldn't do.
This stack could solve, in my opinion, >50% of all business software.
I have also considered some sort of general data storage but it's too slow. Drop box et al are not made for anything close to real time communication, which is critical for a spreadsheet that needs to talk to a program. Something like 100ms at most. This would also presumably require a perfect .xlsx implementation to read and edit the data which doesn't exist to my knowledge.