The distinct lifecycle, row grain, or owner that was checked for and ruled OUT — why these are the same row, not merely similar. Tables stay SEPARATE (not absorbed) when an absorbed table owns a support/profile/approval/ request/detail/history/audit/event/snapshot lifecycle the survivor lacks — in particular a 1:1 profile/account satellite carrying its own fields the actor/parent survivor does not store, since absorbing it would silently lose those fields.
The tables proven duplicate, collapsing into the survivor. When three tables are the same concept, all three are listed in this one action rather than split into separate 1:1 actions. Table names are matched globally.
Why one existing canonical table already preserves the SAME stored concept, owner, row granularity, retained fact categories, and lifecycle as every table being absorbed. Decided first; the merge is its conclusion, never a backfilled justification.
The existing canonical table kept as survivor — may live in any component. Each absorbed family's dependent tables migrate under this survivor prefix.
Type discriminator for absorb.
A finalize-stage absorption of one or more duplicate table families into a single surviving canonical table (N into 1).
Absorbing deletes the absorbed tables and re-parents their dependent children under the survivor prefix; the survivor's columns are built later from the survivor's own concept alone, so it is safe only when the survivor already covers every fact category, owner, row grain, and lifecycle of each absorbed table.
Author
Samchon