> On May 8, 2020, at 2:57 PM, David G. Johnston <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” 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
