> On May 8, 2020, at 3:52 PM, Fehrle, Brian <bfeh...@comscore.com> wrote: > > 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. >
Uncle. And you’re stuck with it because no-one joins back to info, I take it? Denormalization writ large. Oh heck do the switcheroo and mail out a magic decoder ring ;) > > From: Rob Sargent <robjsarg...@gmail.com <mailto:robjsarg...@gmail.com>> > Date: Friday, May 8, 2020 at 3:05 PM > To: "David G. Johnston" <david.g.johns...@gmail.com > <mailto:david.g.johns...@gmail.com>> > Cc: "Fehrle, Brian" <bfeh...@comscore.com <mailto:bfeh...@comscore.com>>, > "pgsql-gene...@postgresql.org <mailto:pgsql-gene...@postgresql.org>" > <pgsql-gene...@postgresql.org <mailto:pgsql-gene...@postgresql.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.g.johns...@gmail.com >> <mailto:david.g.johns...@gmail.com>> wrote: >> >> On Fri, May 8, 2020 at 1:51 PM Rob Sargent <robjsarg...@gmail.com >> <mailto:robjsarg...@gmail.com>> wrote: >>> >>>> On May 8, 2020, at 2:43 PM, David G. Johnston <david.g.johns...@gmail.com >>>> <mailto:david.g.johns...@gmail.com>> wrote: >>>> >>>> On Fri, May 8, 2020 at 1:41 PM Rob Sargent <robjsarg...@gmail.com >>>> <mailto:robjsarg...@gmail.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 >
