Hi, I'm camping in Texas in July, and you can tell I'm growing a little bit of a beard, I thought it might be appropriate to record some sessions on a very hairy set of topics. To go along with how I look here. These topics deal with data effective joins and with reclassification problems. And these problems are not very easy to to solve. Let's see if I can help make them a bit more understandable. We've talked a lot about assigning attributes to maintain balances and in a theoretical way, you could take all of the attributes that describe any balance and you could just stick them on to the to the balance.

You could stick customer names, addresses, the states they live in, the credit ratings, everything about customers, everything about vendors. is the kind of vendor that they are all those attributes could be stuck on to each transaction. Now that becomes as we talked about enjoying processing becomes a bit inefficient for storage purposes because we're repeating the data over and over and over again on many different balances. And so if we make a change to any one of those things, we've got to go update all of those things. So storage and update processes become complex when we do that. So we don't do that.

No one's suggesting we ever do that. But if we were to do that, then we've got a little bit of a problem in that when, when one of those things changes. For example, the the owning department for customer, let's say that the owning department is assigned on the each customer balance. Then if if we want to take and reorganize the company, and let's say that this city, this department owns a territory and one of their outlying cities right on the edge with another department, and somebody says, you know, for reorganization is going to make more sense for us to send these customers to be managed by this new department. Well, now we've got kind of a problem, if we've assigned the department number to the balance has to maintain the balances by that by that department, because we report customer and other sorts of balances by departments quite frequently, then, what do we do when we make a change?

Well, one thing we could do is we could just simply start recording new transactions against the new department. Now then, then all of the historical balances that were for those sales that went to that customer, whatever, those will continue to show up in the old department, and the old department will get credit for them as long as they get credit, you know, if they are given credit for, you know, the last 60 days of sales or whatever, they'll get Continue to get credit for everything that was sold. And then any new sales that show up under the new department would be under the new department ID. So that's, that's a useful way they could satisfy some set of things that were interesting problems is going to come when we start to do try to do customer reporting, because my customer didn't change. My customer is the same customer they live in the same city they purchase from the same stores probably.

It's was an internal reorganization. But now I have two different balances for the same customer, some under department one and some under department two. Now I could solve this simply by aggregating out department and produce customer reports by department. But there's a you know, there are other types of reports where that doesn't work so well. There are times when We need to be able to see an aggregated view of how things have switched how things have changed. For example, ownership of my, my new department, if they start getting credit for the new sales, that's fine.

But if those new sales start to show up as something that's increased their sales, that's not quite right. Because these are existing customers and the old department, the old department looks like they stopped selling to these customers. So they get punished. Well, that's not quite right. These customers just continue to exist and neither department did anything. It was someone else that made the decision to switch customers.

This problem of assigning attributes to balances creates a problem of possible reclassification, when those attributes change in Some way. So we're going to talk in the next few episodes about the implications of that, and how that might be handled and the complexities that come along with those kinds of problems. We'll talk about a couple of different ways that you can manage it can have a switch view, that things just change. It's what kind of what I've described already, you can have a recast view, where you change and switch everything over. Or you can have a reclass view and date effective processing data. Effective joins are essential for us to be able to do these kinds of things over time without having to make new master files.

So we'll talk about that in the next few episodes of conversations with Kip