For contained concept, in the DB based backing store, there is secondary table named with D_<parentConceptNmae>_child created with the following 3 columns to maintain the relations between parent concept and contained concepts:
pid$ numeric(19), valPid$ numeric(19), id$ numeric(19)
pid$ - is for the parent concept id
id$ - is for the contained child concept id
valPid$ - is number, starts from 0 and maps to the index of contained concept in the ContainedConceptArray.
The default behavior on this secondary table is, each time when there is any update to parent concept, all records in the child reference table of the parent concept are deleted and recreated with valPid$ from 0 to (number of contained concept - 1).
The JDBC backing store updates for certain changes to contained concepts (especially arrays) were slow when the contained concepts array is large.
The property
be.backingstore.containedconceptarray.addremove=true can be added to CDD file at cluster level to improve the performance for the following changes:
• The parent concept is modified.
• The child concept is modified.
• The child concept is added or removed.
When
be.backingstore.containedconceptarray.addremove=true is set, there is no deletion to all existing records of a parent concept from the secondary table.
Addition to contained concepts are maintained without touching existing contained concepts. valPid$ is maintained within each RTC starts from 0 and it still has different values depending on how many entries are added in that RTC.
The
be.backingstore.containedconceptarray.addremove property is false by default. It can be used together with the property '
be.backingstore.unmodified.skip' to further optimize database operations.
NOTE: Do not use
be.backingstore.containedconceptarray.addremove=true property if there are changes to contained concepts where the position of the child concepts is modified or if a child concept is nullified. If you choose to do so, note that the modifications are not written to the database.