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

• #6016 lanszelot addikt Magnat #6015

  Új Válasz 2025-08-19 18:53:54 #6016

  Ú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

  Privát üzenet küldése

  

  lanszelot

  addikt

  válasz Magnat #6015 üzenetére

  Hello,
  Hogy kell létrehozni táblát úgy, hogy az id-je egy másik tábla id-je legyen? (Utolsó előtti sor.)
  CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
        username TEXT    NOT NULL,
      email TEXT)
CREATE TABLE IF NOT EXISTS order (
        id FROM users(id),
      address TEXT)

• #5980 martonx veterán Magnat #5979

  Új Válasz 2025-03-18 12:49:38 #5980

  Ú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

  Privát üzenet küldése

  

  martonx

  veterán

  válasz Magnat #5979 üzenetére

  Jaja, csak ötleteltem, ha már ennyire gyorsan változó adatokról van szó. Az egész rendszer ismerete nélkül, nekem látatlanban ez az egész inkább architekturális hibának tűnik, mintsem megoldandó problémának.

• #5977 Magnat veterán Magnat #5976

  Új Válasz 2025-03-18 09:45:59 #5977

  Ú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

  Privát üzenet küldése

  

  Magnat

  veterán

  válasz Magnat #5976 üzenetére

  Sorry, a lock table a truncate elé kerül:

  BEGIN;
  LOCK TABLE tábla IN EXCLUSIVE MODE;
  TRUNCATE TABLE tábla;
  INSERT INTO tábla SELECT * FROM másik_tábla WHERE feltétel;
  COMMIT;

• #5519 nyunyu félisten Magnat #5515

  Új Válasz 2022-05-26 23:56:38 #5519

  Ú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

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz Magnat #5515 üzenetére

  Hja, ha SQL Servert használsz akkor próbálkozhatsz az archaikus Teradata upsert szintaxissal is, hátha megeszi:
  (Elvileg 2008R2-vel próbálták átcsábítani a Teradata DWH júzereit, aztán a legacy kód migráció megkönnyítésére implementálták a Teradata szintaxisát is.)

  update cc
set cc.cust_partnerkod = cc.cust_partnerkod + x.rn
from cikktorzs_customer cc,
(select id, row_number() over (order by id) rn
from cikktorzs_customer
where cust_partnerkod = 200000) x
where cc.id = x.id;

  (Hmm, MS csak a SET és a WHERE között engedi a FROM utáni tábla felsorolást? Teradatában a SET elé is lehetett írni, sőt legtöbbször úgy írták.)

  De a feljebb írt mergenek biztosan működnie kéne, az a több táblát összefésülő műveletek szabványos írásmódja.
  FROM clause nagyon nem szabványos az update szintaxisokban, nem sok DB ismeri, kezeli.
  (Oracle alatt meg se próbáld!)

• #5518 nyunyu félisten Magnat #5514

  Új Válasz 2022-05-26 23:49:36 #5518

  Ú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

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz Magnat #5514 üzenetére

  ""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 ..."

  Meg kell határoznod, hogy
  - melyik sorazonosítóhoz
  - milyen értéket szeretnél rendelni.
  Ezekből létrejön sok (id, érték) páros, ami kvázi egy újabb tábla/nézet/alselect, ezt kell összefésülnöd az eredeti tábláddal, az meg join művelet.

• #5517 nyunyu félisten Magnat #5514

  Új Válasz 2022-05-26 23:33:39 #5517

  Ú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

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz Magnat #5514 üzenetére

  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.

  Írtál egy alselectet, aminek összesen 1 rekord az eredménye, és értelmes join feltétel híján sikerült Deschartes szoroznod a tábláddal, vagyis minden sorhoz ugyanazt az 1 értéket rendelte hozzá.

  Ha az alselectednek nem 1 sor lett volna az eredménye, akkor DB errort kaptál volna, mert egy mezőnek nem lehet egyszerre több értéket adni.

• #5516 martonx veterán Magnat #5515

  Új Válasz 2022-05-26 21:54:58 #5516

  Ú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

  Privát üzenet küldése

  

  martonx

  veterán

  válasz Magnat #5515 üzenetére

  Akkor csináld kurzorral.

• #5511 nyunyu félisten Magnat #5510

  Új Válasz 2022-05-26 16:43:58 #5511

  Ú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

  Privát üzenet küldése

  

  nyunyu

  félisten

  válasz Magnat #5510 üzenetére

  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;

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