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

• #4460 nyunyu félisten kw3v865 #4459

  Új Válasz 2020-03-25 11:51:57 #4460

  Ú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 kw3v865 #4459 üzenetére

  Mi volt a baj az eredeti elképzeléseddel?

  FOR nem a mögé írt query által visszaadott sorrendben megy végig a sorokon, mint ahogyan a kurzorok tennék? De.

  Indexelős ötleted nagyon elborult, egyrészt nehéz megvalósítani, pl. mi van akkor, ha jön egy új elem a táblába, akkor minden sort megupdatelsz az aktuális sorrend alapján?
  Iszonyúan nagy overheadet produkálnának az ehhez szükséges triggerek.

  Ha csak annyi lenne a kérdés, hogyan tudod megmondani egy sorról, hogy ő valamilyen rendezés szerint hanyadik a táblában, akkor a row_number() over (order by x,y) függvényt tudod használni.

  Egyébként meg a relációs adatbázisok mindig halmazokkal dolgoznak, nem egy-egy elemmel, így a más programnyelvek procedurális gondolkozásmódja (ciklusok, kurzorok...) SQLben sosem ad jó teljesítményt.
  Próbálj inkább úgy gondolkozni, hogyan lehet egy queryvel az összes adatot egyszerre frissíteni/beszúrni.

  Előző projekten amúgy belefutottam hasonlóba, mint amit most szeretnél.
  Örököltem egy kódot, ami egy táblából csinált egy rendezett kurzort, majd azon ment végig egyesével, és dinamikus SQLben kért új értéket egy szekvenciából, majd updatelte rá a tábla soraira, kvázi új indexet vezetett be.
  Persze, hogy 15000 sor esetén húsz percig szöszmötölt rajta az Oracle.
  Megoldás az lett, hogy egy segédtáblába leválogattam a fő tábla azonosítóit, meg a row_number() over (order by x,y) rn-t, aztán következett egy jól irányzott merge a fő táblára.
  Egyből lefut 10 másodperc alatt...

  [ Szerkesztve ]

  Hello IT! Have you tried turning it off and on again?

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