Re: Thoughts on how to avoid a massive integer update.

David’s assessment is correct (and I think we’re all on the same page). The value of the foreign keys that tie the tables together must be changed, and yeah that value _should_ simply be an additional column in the info_table and the foreign key be an arbitrary integer, but since it wasn’t set up that way from the beginning (over a decade ago), this is what I’m stuck with.

Blah.

From: Rob Sargent <robjsargent(at)gmail(dot)com>
Date: Friday, May 8, 2020 at 3:05 PM
To: "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "Fehrle, Brian" <bfehrle(at)comscore(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Thoughts on how to avoid a massive integer update.

[External Email]

On May 8, 2020, at 2:57 PM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com<mailto:david(dot)g(dot)johnston(at)gmail(dot)com>> wrote:

On Fri, May 8, 2020 at 1:51 PM Rob Sargent <robjsargent(at)gmail(dot)com<mailto:robjsargent(at)gmail(dot)com>> wrote:

On May 8, 2020, at 2:43 PM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com<mailto:david(dot)g(dot)johnston(at)gmail(dot)com>> wrote:

On Fri, May 8, 2020 at 1:41 PM Rob Sargent <robjsargent(at)gmail(dot)com<mailto:robjsargent(at)gmail(dot)com>> wrote:
My understanding is the keys in the info_table need to change. That causes the very expensive update in the update in the data tables. No?

The keys in the info_table need to change because their contents are no longer legal to be stored (OP has not specified but think using an integer value of someones social security number as a key). The FK side of the relationship equality has the same illegal data values problem and need to be changed too.

Wow, I couldn’t disagree more ;)

Your agreement or disagreement with the problem statement is immaterial here - the OP has stated what the requirement, for which I have made a simplistic analogy in order to try and get the point across to you. As the OP has said it is a poor design - and now it is being corrected. The request is whether there is some way to do so better than the two options the OP already described.

David J.

Sorry, I wasn’t disagreeing with the problem statement. OP did say the “info.id<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2finfo.id&c=E,1,l7B8bw8isNYaTDkm2_hIVb79FGTulxe9Tia8l_UH_XSHi2D5lYB_8XDLez1wLFLAJRgh9Pmyu4VZJSklgkgItDzOjCQxP-MtImoIUALMbg,,&typo=1>” needed to change from 123 to 456. With the current foreign key alignment that is very expensive. I think we’re all in agreement there. To push “456” back out to the data table I see as perpetuation of the problem. I didn’t sense that OP felt it necessary to continue in the current mode as a requirement. If so, my mistake