A megrendelő 2026-08-27-én hat esetben jelezte, hogy két külön névcsoportunk
valójában ugyanaz a cég: a rövid név és a cégformás név (Kőröstej / Kőröstej
Kft, Pick / Pick Szeged Zrt, White Lake / White Lake Kft, ...). A
névnormalizálás ezt nem tudhatja, mert a nevek érdemben különböznek.
- buildPlan a LAP "Csoport" oszlopa szerint csoportosít, nem az adatbázis
normalizálása szerint. Így a lap szélesebb csoportot is kijelölhet - a
végrehajtásba nem kell csoportokon átívelő logika.
- validateGrouping: a lap szélesebb csoportot csinálhat, SZŰKEBBET nem. Ha az
azonos nevű rekordok külön csoportba kerülnének, a végén két azonos nevű
gyártó maradna, vagyis pont a duplikációt állítanánk elő. Ilyenkor a csoport
kimarad a végrehajtásból, nem csak figyelmeztetés.
- a megtartott REKORD továbbra is a legtöbb terméket tartalmazó (a legkevesebb
sor mozdul), a NEVE viszont a választott cégnév
2 új teszt a csoportokon átívelő összevonásra és a szétszórás elutasítására.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
