On Tue, Oct 16, 2012 at 9:47 AM, Rick Debay <rde...@accessrxs.com> wrote:
> > neither of these constraints make any sense (the PK itself assures > uniqueness) > See the posts with the title "Unique foreign key for child tables." It's > needed to be the target for a foreign key. > > > UPDATEs used to be slow for non-selective indexes > This is what I'm trying to avoid. Does anyone know it was changed and > what version? We won't finish the migration from FB 1.5 until year end. > > Update is fine for the compound index you described because the full key is guaranteed to be unique. In version 2.0 (I think) the index algorithm was changed so indexes promote the record number to the upper levels, making every key unique. Makes the indexes a bit fatter, but avoids horrible garbage collection behavior. Good luck, Ann [Non-text portions of this message have been removed]
