Join. Hi, I'm in New York City, I thought we'd talk a bit about join processes today, we could talk for quite a while about trains, there's a lot of information to be known about them. There's a lot of different kinds of joins. database theory has a lot of different information that we could talk about. I'm not going to go through all of that detail, you might be glad that I've gone through a lot of other kinds of detail and posting so far. For our purposes.

Today, I think we'll talk about something much more simple, a simple kind of join, which is called a lookup. A lookup is basically something that goes from a high cardinality, a lot of data, a file that has many different values of the same kind in it to a file that has a specific single target value in it. A joiner lookup of this nature would be something that's probably been done for centuries now. Originally, the clerk would not have copied for example, the account name To each row of the ledger, the account name would have taken more time to copy on each row, they would have just used the account number. Then when they needed to make a report, though the number isn't as meaningful as the name. So they would have referred to the chart of account, which actually had the account number and next to that it would have had the name of the account.

So when they made the reports, they might have written down the account number next to it wrote down the name or just substituted the name for the account number on the report. This process is done the same way when we made when we automated the systems and computers. We stored the account name separately from all of the data that had all of the ledger information in it. This is efficient for two reasons because the data is stored once for storing the name. So that minimizes the amount of storage it's not copied on many different rows. It's also efficient for update purposes.

If the name changes for some Reason, over time, we decide to improve it or become more specific about something, we only have to update it in one place. And every time it gets used, it will be right. This efficiency process is great for updates and for storage, but it's not very helpful when it comes to usage, because it takes computing time for us to go find the name and put it on the reports. And if we're producing many different reports, we're doing those same processes over and over again, the same as if when the clerk did it manually, they would have to search the account table to find the names and write them down. And it's not very fast to do that. So that process is something that goes on over and over again, in reporting processes.

Even just simple lookups. And to build a metric engine, we will certainly have to deal with this complexity, because we need the efficiency that comes from posting processes to get rid of transaction detail, but we also need to be able to use that data efficient And producing many different kinds of reports. So we'll talk more about lookups and joins and how metric engine would have to deal with them in future episodes.