Okay, I'm riding a bike on my camping trip here. We're talking about hot and sweaty and hairy problems. Let's talk about reclass processing. So reclass processing, as opposed to switch processing is, is where we take and change the nature of history. So for our department that is switched over to a, our customers that just switch from one department to another, we we take and flip them into the new department and we go back and we change either the transactions or the balances to reflect the new department. That's recast we recast history, change history, recast it to a different way.

Looking at the work now, that has some drawbacks, right? Changing history is always kind of a negative thing when it comes to data. Because we like to know what the history was, and why the history was the history, why things were the way they were. So if we don't want to actually go step on the balance, and change it to the new department, and or change the transactions to the new department, if we're doing transaction based processing. Well, okay, then there's an alternative we could do. We can use.

You can pause for a moment because we're going down a steep hill, and we're kind of concerned about crashing. Maybe we'll pause this for just a minute to pick up just a moment more. Okay, so someone once said, wisdom is the better part of valor. Better standstill while recording. So if we don't want to change history, what other options do we have? Well, we could maintain two different master files.

We could have one master file that is a switch of view and another master file. It's a recast view. That would be one way of producing the bolts reports multiple results that we want. What's the downside to that? Well, of course, it's reconciliation. Now we have to update to master files going forward.

And the complexity, the data supply chain costs, the adjustment, all of that goes along with that approach. Is there another way of getting around this? Well, one other way to get around this is if we, if we do a date effective joint, let's just be clear for a moment. A joint process would not necessarily solve this problem if all we did was not stamp the transactions or balances with the department ID and instead we use some other key To go join and find the department ID, it wouldn't necessarily solve the problem. Either we, we, what, what typically happens when you use a join is that you end up with a recast view by default, because you change the department associated with a set of customers. And now all the history whenever you produce a historical report, all of those balances, which used to be under one department, because there's only a single row of data in the lookup table, all of those have switched over to the new department.

So recast is the default answer that comes by doing a joint process. So in the next episode, I think we'll talk a bit more about how date effective joins could help us to combine these two different perspectives and get the same result off of the same set, same master file or same set of transactions. Without having to duplicate produce master files or step on history, to be able to produce both kinds of reports