|
|
|
|
|
by UnoriginalGuy
4805 days ago
|
|
Unless you write SQL queries that use stored procedures or pre-calculated results tables, and then you just wind up in the same situation as Excel. I mean Excel is at its heart a query language. So your logic equally applies to Excel, why not write a massive query in Excel that does all the calculations in one go so you can see the inner workings? All you're really doing is playing musical chairs with the data. SQL query language for Excel query language, and data moved from tables to worksheets. As I said earlier, unless there are procedural changes upstream nothing will change. A tool is just a tool. You can use it in a way to minimise mistakes, or not. Humans are the weak point. Now there are tools that automatically identify common mistakes but neither Excel or SQL/relational database engines are in that class. |
|
The least readable query language ever. Instead of names, everything must be addressed as column,row. Imagine a C program that instead of declaring variables with sane names as needed, simply created a large array of each type and used constant numeric indecies. That's what Excel requires.