A megelőzés után a már felhalmozódott adat takarítása: 70 duplikált névcsoport,
146 rekord, ebből 76 beolvasztandó.
Két parancs, mert a kivezetés három környezeten megy (local -> d2d -> éles), és
minden környezetnek SAJÁT duplikátum-készlete van - a döntési lapot ezért ott
kell újragenerálni, nem beégetett ID-listával dolgozunk.
- producers:dedupe-report — döntési xlsx a megrendelőnek. A megtartandó a
legtöbb TERMÉKKEL rendelkező rekord (döntetlennél több rendelési tétel, majd
régebbi rekord); a végleges nevet a megrendelő hagyja jóvá, mert 48 csoport
csak kis/nagybetűben tér el, és az írásmód üzleti döntés.
- producers:dedupe — alapból csak kimutatás, --apply hajt végre.
A lapot FEJLÉCNÉV alapján olvassa, nem oszlopbetű szerint, így a megrendelő
beszúrhat oszlopot vagy átrendezheti a lapot anélkül, hogy eltörne.
Hiányos csoportot és ismeretlen azonosítót visszautasít.
- Visszafordíthatóság: a jelentés SORONKÉNT tárolja a régi producer_id-t, mert
a fordított leképezés azokat a sorokat is átírná, amelyek eredetileg is a
megtartott rekordra mutattak. --rollback ebből állít vissza.
- Tartós nyom a jelentésfájltól függetlenül: a beolvasztott rekord archive +
canSee=0 lesz, és a note-jába kerül, hova olvadt be.
- A két nagy táblán nincs index a producer_id-n, ezért táblánként EGY UPDATE
fut CASE leképezéssel - 76 külön WHERE 76 teljes scant jelentene.
Mért eredmény a d2d másolaton: 27 mp alatt 314 termék + 27 272 archív + 115
árlista-sor átírva; a vizsgált árlistán a "Módosult" sorok 126 -> 23, a
gyártó-diffek 114 -> 2. Visszagörgetés után minden szám visszaállt, és az
újraszámolt diff ismét 126 - az ok-okozat mindkét irányban igazolt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2ced04c086