Let's pull all of this down to earth out of the ether and start to talk about a specific example. Imagine there's a small bakery with a handful of employees. This bakery is a single location with just a owner, a couple cooks and a dishwasher. This bakery maybe wants to report on the type of cookies or the types of pies they sold by week, and it's gonna be edited up by the boss and shown to the bank to justify getting a loan.

So there's not really any complexity here. There's not multiple stakeholders. There's one person editing it with a simple sheet of pies and cookies sold. Compare that now to a much larger bakery with 12 locations, 200 employees. And now you need to do complex slices, such as the type of cookies sold by location on a date, and then you have multiple locations reporting in their sales. You could see how this starts to become too difficult for just a spreadsheet to matter.

But let's slow down and go into an analysis over how can we kind of make this judgment point and put it in roles that you, the person watching this video and hopefully enjoying this content, can start to understand, should you be using a spreadsheet or should you be switching to a database? So to go through the exercise of what we've been discussing so far, think about who is going to be editing the database or the spreadsheet.

In this case, we're talking about a cafeteria slash bakery, and there's only a couple of employees. So make a list of who will want me to enter data or access data and consider what that is. In this case, just to bring you along with the story, we have five employees of which one person needs to be doing edits. There's about 150 items of stock, and there's a physical inventory count every few weeks. This right here is a limited set of data. Inventory data such as this is flat. It's no more than 150 rows, and there's not too many columns just to keep track of counts.

A concept we haven't really begun to discuss in-depth yet, but it will be coming in the series, is the idea of a data model. This is a discussion that is a little more in-depth than we'll cover here, but just know what the concept, a data model is simply an outline of what information you're looking to store and how you're looking to portray it.

Here, you can see a simple list, flat data model. There are six columns and each row is one SKU. So when we talk in terms of data models, and again, we're not gonna go too in-depth here, just know that the left-hand column is the unique, where each SKU is unique, and the rest of the information is data that relates to it. This will come up more in courses to follow, but just try to create a basic data model for your data and fit it into something like this.

If it goes in nicely like you're seeing here, a simple flat list, maybe it's a good candidate for a spreadsheet. And remember, the second criteria is who is going to be updating your data set or your spreadsheet? Think about who is accessing it. But in this case, just to tie it all back to our small baker example, just the boss is updating the data in Excel on her personal computer.

For those of you doing this exercise yourself, think about how you need to report the data. What type of information are you looking to portray? Is it dynamically updated? Is it live updated? Do you need to have data audited by a third party with an audit trail?

In the case of this small bakery with one boss and five total employees, there's no need for that. So in this case, we're able to say that a spreadsheet is actually a really good option for this bakery. For those of you watching, perhaps you're in a bigger company, don't think that just because you're in a 10,000-person company, you need to go to a database. If you're working in a 10-person team, perhaps a spreadsheet is great for you, but let's move beyond that. Let's assume that you need to start working with a database. Let's discuss what your considerations are and how you can start to pick out the right one.