Új hozzászólás Aktív témák

• Magnat veterán

  #5514

  #5511 nyunyu

  2022-05-26 19:51:52

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Magnat

  veterán

  #5511 nyunyu

  #5511 nyunyu

  Javaslom a szabványos merge szintaxis tanulmányozását.

  Sok fejfájástól megment, ha több tábla joinja alapján kell updatelni egy táblát...

  Egyébként már az updateedet sem értem, miért kéne többször lefutnia az alselectnek, ha egyre limitáltad a visszaadható eredmény számát?
  Meg a join feltétel is kompletten hiányzik, ami alapján leválogatnád, hogy melyik rossz sorhoz milyen jó partnerkód tartozna.

  Ez most pont azt csinálja, hogy leválogatja a legnagyobb partnerkódot, és annyi+1-et ráupdatel minden 200000-es sorra.

  Ezzel maximum annyit tudsz csinálni, hogy beteszed egy kurzorba az összes 200000-es sort, aztán egyesével végigiterálva rajtuk mindig eggyel nagyobb értékkel updateled őket.

  Vagy valami nagyon elborult merget írsz, ami besorszámozza a sorokat, aztán az alapján updatel:
  merge into cikktorzs_customer u
using (select cc.id, cc.cust_partnerkod, row_number() over (order by cc.id) rn
from cikktorzs_customer cc
where cc.cust_partnerkod = 200000) x
on (u.id = x.id)
when matched
then update set u.cust_partnerkod = x.cust_partnerkod + x.rn;

  "Sok fejfájástól megment, ha több tábla joinja alapján kell updatelni egy táblát..." - de ez egy tábla ...

  "Egyébként már az updateedet sem értem, miért kéne többször lefutnia az alselectnek, ha egyre limitáltad a visszaadható eredmény számát?" - azért, mert egy rekordhoz egyszer kell lefusson, de az első update után változik az adatnézet, ha akkor újra kiértékelődik a belső select, akkor már az eggyel növelt értékű rekordot kellene (mármint a logikám szerint) megtalálnia.

Új hozzászólás Aktív témák