- Local time
- Today, 11:30
- Joined
- Feb 28, 2001
- Messages
- 28,386
I'm going to make a generic statement here. When you say you update something and then later see that it appears to have not been updated...
Frequently this comes from a type of normalization violation in which you have duplicate secondary characteristics in two tables. You update one, but the other copy of the characteristic is not updated. Think back to our earlier discussion of "Status" where you wanted both the Parent table and the Child table to retain the status, but we convinced you that status only belongs in one place as a matter of normalization. And your problem was that if you changed the status in one place, it didn't automatically update in the other place.
What you are describing now sounds extremely similar to the previous "Status" problem, in which you change something someplace but not in another place, so you get conflicting or out-of-date statuses. One of the principles of normalization is that you have a definite place where some characteristic is stored. We sometimes call that the "definitive authority" for the particular item. In our previous discussions about status, you came around to realize that the transaction table was the definitive authority for Status. To see that status, you had to always query it from the definitive source and anything else that needed that status should have ALSO queried that source rather than having a separate and distinct copy.
The idea here is "isolation of purpose." There should only be one place to look for a sample status AND its location while it is in that status, including department and any other dynamically changing locator information.
This problem with "change of department" sounds similar to the earlier problems. Maybe it isn't, but the symptoms you described sound extremely similar. For what it is worth, if the problem really IS simply incomplete normalization, you aren't alone in making that mistake. It happens a lot, particularly when the project is very complex and has lots of "moving parts" (or data interactions, if you prefer).
Frequently this comes from a type of normalization violation in which you have duplicate secondary characteristics in two tables. You update one, but the other copy of the characteristic is not updated. Think back to our earlier discussion of "Status" where you wanted both the Parent table and the Child table to retain the status, but we convinced you that status only belongs in one place as a matter of normalization. And your problem was that if you changed the status in one place, it didn't automatically update in the other place.
What you are describing now sounds extremely similar to the previous "Status" problem, in which you change something someplace but not in another place, so you get conflicting or out-of-date statuses. One of the principles of normalization is that you have a definite place where some characteristic is stored. We sometimes call that the "definitive authority" for the particular item. In our previous discussions about status, you came around to realize that the transaction table was the definitive authority for Status. To see that status, you had to always query it from the definitive source and anything else that needed that status should have ALSO queried that source rather than having a separate and distinct copy.
The idea here is "isolation of purpose." There should only be one place to look for a sample status AND its location while it is in that status, including department and any other dynamically changing locator information.
This problem with "change of department" sounds similar to the earlier problems. Maybe it isn't, but the symptoms you described sound extremely similar. For what it is worth, if the problem really IS simply incomplete normalization, you aren't alone in making that mistake. It happens a lot, particularly when the project is very complex and has lots of "moving parts" (or data interactions, if you prefer).
