News Formula 1 management shocked team used Excel for 20,000-part inventory, now replacing 'impossible to navigate' sheet

Toggle sidebar Toggle sidebar
Done correctly Excel is fine for such a small parts book (similar databases underpin many parts management suites). Sounds like this wasn't done correctly a an Excel database is only as good as the person who made it. That said, there is better software, it just costs a LOT of money. I think ours is many thousands of dollars per month, but it is a whole suite and our database has millions upon millions of individual sku's.
 
CelicaGT said:
small parts book
Click to expand...
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.
 
  • Like
Reactions: Corwin65, Chips4all, bit_user and 1 other person
USAFRet said:
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.
Click to expand...
In comparison to retail or industrial it is a tiny number of sku's. Still not something I'd use Excel for as it gets veeeery sluggish and there are all kinds of network access issues in my experience. When many are accessing, only one can have write privilege. One of our larger customers uses Excel as a planning database. It is awful. And this is a 40 billion dollar company I am talking about..... I once used one at a shop I once worked at that the owner wrote, it could do everything a modern parts management system can with the exception of auto ordering sku's that had reached -min- level. The field would change colour once -min- was reached so it was kinda useful with the small number of sku's we had there.The only reason this was done was cost. Small rural shop run by very cost conscious people.
 
  • Like
Reactions: Chips4all and bit_user
CelicaGT said:
In comparison to retail or industrial it is a tiny number of sku's. Still not something I'd use Excel for as it gets veeeery sluggish and there are all kinds of network access issues in my experience. When many are accessing, only one can have write privilege. One of our larger customers uses Excel as a planning database. It is awful. And this is a 40 billion dollar company I am talking about..... I once used one at a shop I once worked at that the owner wrote, it could do everything a modern parts management system can with the exception of auto ordering sku's that had reached -min- level. The field would change colour once -min- was reached so it was kinda useful with the small number of sku's we had there.The only reason this was done was cost. Small rural shop run by very cost conscious people.
Click to expand...
Exactly.

20k "items" is not that much.

But it depends on exactly what they're doing with it.
Just a list is one thing. But once you add in all the potential inter-dependencies and other functions....Excel is NOT the tool for this.

The clown that built this, and then follow on clowns that modified it....shame on them.
It is now unusable and unmanageable.

A proper database application would easily work.
 
  • Like
Reactions: CelicaGT, bit_user and coolitic
In regards to size the number parts doesn't really matter. It's how many transaction and how frequently they happen that kills Excel as a simple database tracker.

If this was just a one man junk yard where he keeps track of all the spare parts he's salvaged in Excel it would work perfectly even up to millions of parts. The low volume of changes keep it very manageable. This is the Excel trap business fall into as most start out in that low volume easy to manage range and then slowly expand into the unmanageable range.

But if you have more than one users and they are are making constant changes it just falls apart. Of course this happens with bull blown billion dollar ERP databases too. If people don't follow procedure religiously the database won't know anything, just ask Boeing what happen to those four bolts.
 
  • Like
Reactions: P.Amini
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.
 
truerock said:
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.
Click to expand...
Excel is not a database.
Excel is not a database.
Excel is not a database.
Excel is not a database.
Excel is not a database.
Excel is not a database.

You can sort of fake it. And that is where this F1 team is now.
But.....Excel is not a database.
 
Fully agree: "Excel is not a database"

All too easy to start violating the rules of normalization.

And imports, updates, queries, reports etc. become a nightmare.

What can be worse is trying to get all of the Excel data, intact, into a real database.

"The key, the whole key, and nothing but the key, so help me Codd."
 
USAFRet said:
Excel is not a database.
Excel is not a database.
Excel is not a database.
Excel is not a database.
Excel is not a database.
Excel is not a database.

You can sort of fake it. And that is where this F1 team is now.
But.....Excel is not a database.
Click to expand...
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.
 
Ralston18 said:
Fully agree: "Excel is not a database"

All too easy to start violating the rules of normalization.

And imports, updates, queries, reports etc. become a nightmare.

What can be worse is trying to get all of the Excel data, intact, into a real database.

"The key, the whole key, and nothing but the key, so help me Codd."
Click to expand...
So, many times the application developers I worked with would get so angry when business analysts would create their own systems with Excel. I just had to keep telling them over and over again that those unprofessionally designed Excel systems would keep us in jobs for many, many years.

My take was to partner with the users and help them "professionalize" their Excel systems - usually after they had been audited and ended up with a bad audit report. They would then be able to pass the next audit. Later we would start adding Oracle backends to support the ever-increasing data volumes and then... well, the users would get bored, and we would take over the application.
 
truerock said:
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.
Click to expand...
Can a series of Excel worksheets and cells be "normalized"?
Yes, sort of.

Is it far more stable to have that exact same data in an actual relational database application?
Yes.

Can you output subsets of that data directly into Excel, for user manipulation?
Absolutely.

But I stand by my statement...Excel is not a database.

I'm out.
 
Yeah, Excel cannot be classified as a "true" database. Period.

After all, a spreadsheet can look very much like a database for a non-database user. I have noticed that it’s often difficult to maintain data integrity using Excel, especially among multiple users.

When the content of the file becomes too large, Excel's performance drops significantly making viewing/editing the data difficult.

Kinda reminds of this issue, where apparently a text file was imported into Excel, but with more lines/records than could be handled in the spreadsheet resulting in the lost records.: 🙄

The badly thought-out use of Microsoft's Excel software was the reason nearly 16,000 coronavirus cases went unreported in England.

https://www.bbc.com/news/technology-54423988

Real and good database examples would be:: PostgreSQL, SQL Server, Oracle, or even more lightweight systems like SQLite.

Excel could be a great tool for data analysis, presentation, math and statistical calculations though, but for storing large amounts of data ? NOPE. In COVID's case, they used it as a replacement for a “real database”, which was a blunder to begin with.
 
Last edited by a moderator:
  • Like
Reactions: bit_user
why_wolf said:
If this was just a one man junk yard where he keeps track of all the spare parts he's salvaged in Excel it would work perfectly even up to millions of parts. The low volume of changes keep it very manageable.
Click to expand...
Seriously? I have a ~1000 row spreadsheet I use for personal reasons. No complex formulas or inter-row relations. No dynamic sorting or anything fancy. It's all basically just static data and formatting. And yet, the more I keep using it, the more sluggish it gets. Certain, basic operations can take up to 1 second. It's stored on a local SSD, too. The xslx file is only 59 kB, in fact.

This is using Excel 2013, since I'm too cheap to upgrade (I bought this version with an employer-sponsored discount, but I missed the chance to upgrade to Office Pro 2017 and they now offer only a discount on Office 365 subscriptions). I don't think that's a good excuse for why it performs so poorly.
 
  • Like
Reactions: Deleted member 2731765
USAFRet said:
Exactly.

20k "items" is not that much.

But it depends on exactly what they're doing with it.
Just a list is one thing. But once you add in all the potential inter-dependencies and other functions....Excel is NOT the tool for this.

The clown that built this, and then follow on clowns that modified it....shame on them.
It is now unusable and unmanageable.

A proper database application would easily work.
Click to expand...
I expect like most things (that planning database I mentioned) it evolved over time and was always "good enough" to those who were to close to the problem. It's often the case that new blood calls a spade a spade and is a great reason to rotate staff, and add new faces.
 
CelicaGT said:
I expect like most things (that planning database I mentioned) it evolved over time and was always "good enough" to those who were to close to the problem. It's often the case that new blood calls a spade a spade and is a great reason to rotate staff, and add new faces.
Click to expand...
Yep.

Good enough.

Until it isn't.

Or until new eyes look at it and say "WTF!!!"
(as is apparently the case here)

Seen it far too many times.
I am that 'new eyes' guy far too often.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom