Excel has one purpose, data analytics, but as it is a very powerful tool in that regard, with loads of flexible features, people tend to use it in ways that will work for a surprisingly long time, before completely failing.
A common example is to build a database in Excel, say a product catalog with all features and pricing listen in dynamic fields, then someone writes a custom macro to interface the database with external systems, and as new employees join more code is written to make the database easier to update and edit, then more systems are brought in to interface with the database, more data is added, say materials needed in production to build said products, and time calculations to findout how long the different products will take to make, and what product you can make with what you have in inventory, and more macros and integrations.
And it keeps going, but Excel has a hard limit on how much data a sheet can contain, and with all of the new features and integrations it will just be a matter of time untill a new update from Microsoft breaks critical functionallity.
And as the Excel database is used for more and more stuff, it becommes more and more dangerous to the company, at the end you will have an unmaintainable mess that is kept alive on a Windows XP VM running MS Office 2003, since that is the latest system that can run the database with all integrations
A proper SQL database is far more efficient robust, and customizable, but require more indepth knowledge about programming.
True, but unless still using .xls instead of .xlsx chances of reaching the row limit on a sheet became rather small, even for very large companies. Many issues with the everything in excel hell, but the row limit isn’t a main one (anymore).
Then you only get the raw data, not macros or integrations, some of which might be more important to the company than data from a specific point in time.
So then It’s a matter of basic data sanitation and code modernization. They’re in a better position than places that are still rocking COBOL code, because every database nerd knows excel wheras only 95% of database nerds know COBOL.
Excel has one purpose, data analytics, but as it is a very powerful tool in that regard, with loads of flexible features, people tend to use it in ways that will work for a surprisingly long time, before completely failing.
A common example is to build a database in Excel, say a product catalog with all features and pricing listen in dynamic fields, then someone writes a custom macro to interface the database with external systems, and as new employees join more code is written to make the database easier to update and edit, then more systems are brought in to interface with the database, more data is added, say materials needed in production to build said products, and time calculations to findout how long the different products will take to make, and what product you can make with what you have in inventory, and more macros and integrations.
And it keeps going, but Excel has a hard limit on how much data a sheet can contain, and with all of the new features and integrations it will just be a matter of time untill a new update from Microsoft breaks critical functionallity.
And as the Excel database is used for more and more stuff, it becommes more and more dangerous to the company, at the end you will have an unmaintainable mess that is kept alive on a Windows XP VM running MS Office 2003, since that is the latest system that can run the database with all integrations
A proper SQL database is far more efficient robust, and customizable, but require more indepth knowledge about programming.
True, but unless still using .xls instead of .xlsx chances of reaching the row limit on a sheet became rather small, even for very large companies. Many issues with the everything in excel hell, but the row limit isn’t a main one (anymore).
That is fair, I was perhaps a bit rash when bashing Excel on that point.
It does still happen. Even in new projects. It happened in Britain on their big COVID19.xls sheet
https://www.bbc.com/news/technology-54423988
Oh yeah, I remember that one…
Thst is a classic example of what Excel is not used for.
The problem is that many of these are xls files.
Step 1: load xls
Step 2: Save as csv
Step 3: ???
step 4: profit
Then you only get the raw data, not macros or integrations, some of which might be more important to the company than data from a specific point in time.
So then It’s a matter of basic data sanitation and code modernization. They’re in a better position than places that are still rocking COBOL code, because every database nerd knows excel wheras only 95% of database nerds know COBOL.