brandonjclark
Distinguished
I think the entire F1 league (and obviously others) could benefit from a structured configuration management program/product ran by an expert who knows how to ETL this stuff into a datalake.
The scheduled forum maintenance has now been completed. If you spot any issues, please report them here in this thread. Thank you!
Oh...so, so many times .... especially in 80's - 20xx in manufacturing.... 45+ year career...LOL fun! ☺️An F1 team is much more than "small".
And they do have a very large budget.
SQLServer, or even MS Access, would have been much better.
And not cost much more, if anything.
People start with Excel, because it puts everything in nice neat rows and columns.
But very quickly run past its capabilities as a database.
As said, I've seen this exact scenario many times.
Yep LOL fun! ☺️. 45 year career -- have T-shirts from manufacturing floors & logoed polo shirts from the cubes .... Yeppers...I worked with the guys who did the excel macros + the original Oracle designers on the initial data models in exactly the time period, mid-80's - 2000 you've identified. After that much more rational oo event- driven data manipulation!1996 : some poor schmuck was tasked with keeping a list of spare parts from an old stack of paper files, then some content was added, then dependencies were bolted onto it, then another inherited it and tried to ad some more stuff on it with macros, then another inherited it and used it for another purpose, then someone else added some more dependencies...
Some people use Excel as a programming environment : formatting, data storage, forms, etc. all packed into one with no consideration at ALL for the principles of Model-View-Controller development, inherited by incompetents (they have another job to do) for DECADES, giving you a completely impossible to understand blob of data, macros and formatting with mistakes all over the place that will take WEEKS to make sense of.
Once you've understood what it's for, then you must model a new software from the ground up and enter the data piece by piece, and then REMOVE all the fixes used by whatever was connecting to the Excel blob that dealt with its idiosyncrasies before you can switch to said proper software.
And that can't be done by a wet behind the ears intern, you need a good analyst and a good software developer, along with a good project manager to follow all of that - that's a $3000 a day job, stretched over 2-3 months at BEST : here, $300 000.
That's what one calls technical debt - had the job been done properly (basic database, a few forms, some script in Perl or Pascal/Delphi or Java) in 1996 when that spreadsheet was created, you could have cut a zero or 2 out of that cost : of course you would have had to reprogram a great deal of it to port it to a modern language, you would have to redraw the views etc. but any programmer worth his/her salt can do that in a few days, the data would have to be migrated to match the new data object model, but at least it would be CONSISTENT ! you usually get a test version in under a WEEK and can do regression testing over a couple more weeks, but you've already saved more than a couple months in debugging time and regression testing more than likely doesn't have to cover as many shims and quirks.
Been there, done that, got the T-shirt.
I love it!!!!Obviously any database should be properly "normalized". That has nothing to do with Excel.
A database is a set of tables (Excel tabs). So, Excel is good at that.
Each data element needs to be defined (Excel, Data, Data Validation)
The relationships between data elements needs to be defined (Excel, Index, Match)
You need to create Excel, Forms to make data entry clear and pre-defined
Having many individuals update Excel simultaneously is usually solved by normalizing the tables within the groups of people updating them.
In 1984, I setup a Lotus 1-2-3 database for a division in a large corporation to perform annual budgeting. Given the technology available at the time, I had to create separate, normalized spreadsheets for individual departments.
SAP is such an expensive beast to use and evolve. Yep....extracting data for a report in excel especially for some accounting work or an audit type engagement is standard for most accounting firms.I remember about 20 years ago, I was brought into project the server infrastructure cost for this huge SAP financial system project for a multinational corporation. I sat in on meetings about financial reports which had something like $20 million budget. I talked them into scrapping the project and just creating a system for selecting and summarizing data to be downloaded into Excel. The consulting company hired to work on the project was SO angry and the accountants were so happy.
Anyway, a properly designed database is a set of relational tables (Excel tabs) that have been "normalized".
If you don't think Excel can be a database - then you do not know what you are talking about.
Issues involving high-performance transactional capture (e.g. airline reservation system) obviously something that Excel can't provide.