normalization done poorly at the bank
November 29th, 2009 by Jeanne BoyarskyI went to a bank yesterday to inquire why I was receiving mail at my old address despite having moved a number of months ago. The first thing the representative did was pull up my record to show me that my address was correct in their system. While that’s very nice, the mail has their name on it. What’s more, I have received mail from this bank at my correct address already.
Then the representative tells me he’ll try to change it again in case the other person didn’t do it right. While doing this he finds the problem and shows it to me. This bank, in all their wisdom, has the customer’s mailing address on two screens. A representative must make the change in two places.
Lessons from this:
- Scott blogged about normalization last year. Having information in two places invites one to be wrong. And we aren’t talking about the name of the state here. Customer address is a piece of information you would expect to change over time.
- If you do have the same data in two places, you should write code that updates both rather than require people to do it.
Comments
Comment from Roshan
Time November 30, 2009 at 10:00 am
One of the banks I have an account with in India operates in an even more bizarre fashion. The address is stored in two different systems, only one of which can be updated by a representative. After a while, the one that can’t be modified is copied into the new one, replacing it. Either that or the interface pretends to change the address. I gave up on them after a couple of tries and just switched banks.
Comment from Jeanne Boyarsky
Time November 30, 2009 at 8:21 pm
Roshan,
Thanks for sharing that. It is so illogical that is is funny. Unless it is happening to you of course.
Comment from Michael Ernest
Time December 1, 2009 at 10:05 pm
My wife’s been trying to get a bounced check returned to her for over a month. Last night she talks to someone who says they have three addresses on file and aren’t sure which is current. So they _started_ with the one on file the longest. I’m thinking, you know, why wouldn’t you pick the address you use to deliver our statements? But I’m no financial whiz…
Comment from Jeanne Boyarsky
Time December 2, 2009 at 9:23 pm
Michael,
How nice. That sounds perfectly logical!
Comment from krishna
Time July 26, 2010 at 6:43 am
Hi Scott
I was using the database normalization tool you had developed at cornell. It is not available now. I am a lecturer and I always suggest my class to use the tool to understand database normalization better. Is there any way I can get access to the tool?
Have a nice day!
Krishna
Comment from Scott Selikoff
Time November 30, 2009 at 3:05 am
Hey Jeanne,
In this case, it’s probably far worse than database normalization, they probably have the data in two entirely different, partially independent systems. I’ve seen bank systems where ‘rolling out the new system’ actually meant supporting the data in both the old and the new system. Either way, I fully agree with #2, if for some reason you have denormalized data, your update methods should always update both locations.
Often times, though, the source of denormalization such as 2 sets of addresses can be traced to feature creep and a lazy developer. At the start, there’s one set of addresses for account information and at some point they decide to a new mailing feature for marketing information. Instead of modifying the original address component to handle both account information and mailing, the developer takes the easy route and writes something entirely new, thereby avoiding reading and integrating the old code. Now you have two modules doing the same thing but with different, distinct, sets of data.
-Scott