All right, welcome back everyone to topic one in our database class. And this part, we're going to focus on problems with storing data in a list. So, let's start now, considering some of the problems that can arise, when we try to store information in the form of a simple list. Okay, so one of the most notable problems with storing information in a list is that as the quantity of information that we're trying to store grows, we would all most inevitably start to have to record things multiple times. When we're talking about lists, we have a situation where say we're just writing down items, and each row, each item on our list is, as it says here, is intended to stand on its own. So, for example, maybe you are, I don't know, writing down a customer's mailing address. So, a customer comes in, they place an order with you, and you need to write down their mailing address so that you can ship the order to them once it's ready. How do you do that? You write down their address, their street address, maybe their postal code, their name, etc, and that's fine. And it works very well if that customer only places one order with you. But if you are keeping track of your orders on a list, and that customer comes in three days later to place another order with you, and you have to write down those order details on your list, you're going to have to duplicate or replicate that to customers' mailing address information again. So, in this case, you are storing the same information multiple times on your list. It is redundant, and therefore is using excess space that is, or would not technically be required if we were to use a more efficient strategy. And this creates additional problems as well, this type of redundancy. As an example, imagine that our customer comes in and says that they've recently moved to a new location, and we need to update their address for all of their outstanding orders. So, that means we need to go through this long list of customer order information that we have, and any time that we find the specific customers' information we will need to update it. So, we'll have to do many updates if that customer has placed many orders with us, because we have redundant information in our list. And if we miss one or two, that is, if we don't make all of those updates for every single order that the customer has placed with us, then suddenly our list contains inaccurate information. And we may, for example, be sending packages to an address where our customer no longer lived. This redundancy can cascade and cause further downstream problems for us. Here's another example that we can consider, in this case, that we might consider a list of projects and a project manager scenario. So, imagine, for example, that we have, the way that we run our company is that we have project managers who manage projects, and each project manager is allowed to manage several projects simultaneously. So, in that case, if we're trying to keep track of all this information on a list, we want to keep track of, say, the name of the project manager, some sort of, I don't know, unique, maybe like employee ID for them, and their phone extension. And if that person is currently managing 10 different projects for us, then we will have to write down their information that is their name, ID, and phone extension, 10 different times on our list. And just like with the customer example that we discussed previously, this naturally introduces a great deal of redundancy and all of the problems that may emerge there from. So, let's continue investigating some of the problems with storing information in lists by considering this notion of multiple themes. So, previously, I use an example of just imagining a world where we are trying to to store in a list format information about customer orders. So, imagine we're storing information about to one order per row. So, it's just if you want to imagine it just as like a sheet of paper or a spreadsheet, so whatever it may be, we're recording information as one order per row. So, in this case, I might have, say, four orders. Now, if we ask ourselves, what information do we as a company need to collect in order to record an order from a customer, we will see immediately that we need several different types of information. So, we may need information about to the customer themselves, say their contact information, their mailing address, their name, and so on. We may need additional information about the products that they are ordering as a part of this order. So, maybe they're buying, I don't know, television and some batteries for an electronic store. So, we need to record the products that we're selling to them. We need to record the quantity of those products, the price of the products, etc. So, you can imagine that there are lots of different things. Maybe information about the salesperson who sold it. So, information about lots of different things may actually be required in order for us to store everything that we need to know about this order. So, we have multiple themes because a customer is a different thing from a product, a product is a different thing from a salesperson. So, each of these separate concepts is going to have some information that we'll need to store in our list. And this notion of storing information about multiple themes all on one row in a list as we will see can create substantial problems for us as well. So, I'll have some examples of this shortly that will illustrate why storing information about multiple things in the form of a simple list, say, customers and the products that they're purchasing and the salesperson who sold those things to them can create some problems for us. So, for now, suffice it to say that we can have issues like certain information appearing on the list only if information information about other things is also present. So, for example, if we have salesperson information that we're storing on our list, maybe that salesperson information only occurs if a salesperson has actually sold something. So, if we have the salesperson information stored here and some of this other stuff, maybe the product information is stored here and we have our customer information stored over here. If this is, say, a new salesperson and they have only sold information or sold products one time for us, then their information will only appear on this list once. Now, for a new salesperson who's never sold anything, we would have no information in our list of data about that. In fact, we wouldn't even know that salesperson exists from a data perspective until they actually make a sale. Now, this is just one of the types of problems or issues that kind of rise. If we try to store information in the form of a list because naturally a salesperson is an employee of ours and we can imagine that we would want to know that they are employees and have information about them stored somewhere, regardless of the fact that they may have not made a sale yet. When we try to store information in lists, beyond just very simple information, we will almost inevitably find ourselves in a situation where we are storing information about multiple themes or multiple business concepts in the same list and that, as we will continue to learn about, can create problems for us.