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

• #5715 Apollo17hu őstag Jim74 #5713

  Új Válasz 2023-04-04 00:06:45 #5715

  Ú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

  

  Apollo17hu

  őstag

  válasz Jim74 #5713 üzenetére

  LAG() vagy LEAD() függvénnyel megképzel 7 extra mezőt, amik az előző, az azt megelőző stb. ... és végül a héttel korábbi fogadást tartalmazzák. Az így előállt 8 mezőt összeadod egy rekordon, és ahol 8-at kapsz, ott volt a nyolcas nyerő széria (vége).

• #5584 Apollo17hu őstag hellsing71 #5581

  Új Válasz 2022-08-31 12:51:56 #5584

  Ú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

  

  Apollo17hu

  őstag

  válasz hellsing71 #5581 üzenetére

  igy esetleg?

  select t.*
  from tabla t
  where case
  when t.m1 = t.m2 then 1
  when t.m1 = t.m3 then 1
  when t.m1 = t.m4 then 1
  when t.m2 = t.m3 then 1
  when t.m2 = t.m4 then 1
  when t.m3 = t.m4 then 1
  end = 1

• #5509 Apollo17hu őstag Hintalow #5508

  Új Válasz 2022-05-10 22:47:28 #5509

  Ú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

  

  Apollo17hu

  őstag

  válasz Hintalow #5508 üzenetére

  utolsó példa

• #5507 Apollo17hu őstag Hintalow #5505

  Új Válasz 2022-05-10 16:32:28 #5507

  Ú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

  

  Apollo17hu

  őstag

  válasz Hintalow #5505 üzenetére

  analitikus fuggvennyel:
  count(*) over(partition by mezo) as ertek_db

• #5468 Apollo17hu őstag tm5 #5465

  Új Válasz 2022-04-12 18:22:13 #5468

  Ú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

  

  Apollo17hu

  őstag

  válasz tm5 #5465 üzenetére

  Ez jo pelda, igazabol ilyen esetben mindegy lenne, mi lesz a besorolas. Sot, meg az is jo lenne, ha beduplikalna az eredmeny, mert abbol latszodna, hogy t2-ben bele kell nyulni a "parameterezesbe".

• #5464 Apollo17hu őstag tm5 #5463

  Új Válasz 2022-04-11 19:01:12 #5464

  Ú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

  

  Apollo17hu

  őstag

  válasz tm5 #5463 üzenetére

  Az m1..mn mezőknek eltérő az értékkészlete. Pl. m1-ben kizárólag 'A'-val, m2-ben 'B'-vel, m3-ban 'C'-vel stb. kezdődő keresztnevek szerepelhetnek, tehát nincs átfedés. Annyiban "egyszerű" a dolog, hogy az m1..mn mezőknek a két táblában ugyanaz az értékkészlete.

• #5462 Apollo17hu őstag

  Új Válasz 2022-04-09 22:17:13 #5462

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok!

  Van egy problémám, amire csak favágó megoldásom van, de érdekelne, hogy megoldható-e elegáns(abb)an.

  Van egy tény tábla (t1), ami tartalmaz egy egyedi azonosítót (id), és további attribútum mezőket (m1, m2, m3 stb.).
  Van egy dimenzió tábla (t2), ami a tény tábla rekordjainak besorolására szolgál. Ebben a dimenzió táblában megvan az összes attribútum mező (m1, m2, m3 stb.), ami t1-ben is szerepel, de itt id helyett egy ún. kategoria mező van. A kategoria mező szintén egyedi. Úgy áll elő, hogy a rekordon lévő attribútum mezőket egyszerűen konkatenáljuk.

  A feladat az, hogy t1 összes sorát meg kell nézni, hova kategorizálódik t2 szerint. A probléma ott kezdődik, hogy az attribútum mezők mindkét táblában hol töltöttek, hol nem (NULL). Értelemszerűen, ha t2-ben töltetlen egy attribútum, akkor az a kategorizálás szempontjából irreleváns (vagyis t1-ben bármit tartalmaz az attribútum, a rekord kötni fog t2-vel). ...és ott folytatódik, hogyha t2-ben bizonyos sorok "tartalmazzák" a másikat, akkor a szűkebb halmaz priorizált.

  Például, ha az alábbi két rekord szerepel t2-ben:

  m1 = NULL; m2 = 'Bela'; kategoria = Bela
  m1 = 'Aladar'; m2 = 'Bela'; kategoria = AladarBela

  ...akkor t1-ben az alábbi rekord:

  id = 1; m1 = 'Aladar'; m2 = 'Bela'

  az 'AladarBela' kategóriát fogja megkapni, mert ugyan 'Bela' kategória is érvényes lenne rá, de 'AladarBela' szűkebb halmazt képvisel (mert nem mindegy, mi kerül az m1 attribútumba).

  Ha t1-ben ez a rekord lenne:

  id = 2; m1 = 'Alfonz'; m2 = 'Bela'

  ...akkor a 'Bela' kategóriát kapná.

  Látszik, hogy a kategorizálás egyértelmű, de nekem nem jut eszembe egyszerűbb megoldás annál, minthogy létrehozzak egy olyan CASE WHEN-t, aminek az ágainak számossága egyezik a t2 táblában lévő rekordok számosságával. És ez azért is gáz így, mert ha t2 bővül/módosul, akkor a CASE WHEN-t is bővíteni/módosítani kell.

  DB Fiddle-ben készítettem két mintatáblát, ha vkit érdekel a problémafelvetés. Köszi!

• #5409 Apollo17hu őstag nyunyu #5408

  Új Válasz 2021-11-24 18:57:05 #5409

  Ú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

  

  Apollo17hu

  őstag

  válasz nyunyu #5408 üzenetére

  Igen, ilyesmiben gondolkodom, koszi. Ezen lehet amugy vmit optimalizalni, hogy gyorsabban fusson?

  megj.: Uj helyen melozom, almomban sem gondoltam volna, hogy ennyire gany az adatbazis.

• #5407 Apollo17hu őstag

  Új Válasz 2021-11-24 15:44:53 #5407

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok!

  Oracle SQL-ben van 3 táblám: "A", "B" és "C". "A" és "C" között "B" kapcsolótáblaként funkcionál. Szeretném megnézni, hogy
  - Vannak-e olyan rekordok, amelyek megtalálhatóak "A"-ban, de nincs hozzájuk kapcsolat "B"-ben?
  - Vannak-e olyan rekordok, amelyek megtalálhatóak "C"-ben, de nincs hozzájuk kapcsolat "B"-ben?
  - Vannak-e olyan kapcsolatok "B"-ben, amelyek sem "A", sem "C" egyik elemére sem mutatnak?

  Egyelőre arra jutottam, hogy először csinálok egy ilyet:

  "A" FULL OUTER JOIN "B",

  majd a kapott halmazhoz hasonló módon hozzácsapom "C"-t:

  ("A" FULL OUTER JOIN "B") FULL OUTER JOIN "C".

  Van ennek a mókának elegánsabb módja? Olyasmire gondolok, hogy lehet-e 3 (vagy több) táblát egy lépésben FULL OUTER JOIN kapcsolni?

• #5237 Apollo17hu őstag nyunyu #5236

  Új Válasz 2021-09-03 16:31:56 #5237

  Ú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

  

  Apollo17hu

  őstag

  válasz nyunyu #5236 üzenetére

  Hat, azt nem tudom, hogy mi hogyan irodhatott, de abban nagyon igazad van, hogyha az ember nem gyakorlott benne, akkor elegge necces a hasznalata. Egy kivalasztott peldara meg nehany masodperc alatt lefutott a kodom, de szazmillios rekordszamom van, ugyhogy inkabb elengedem a rekurziv temat. Igazabol csak egy szep megoldast kerestem, mert mas modon kozel 100%-os pontossaggal meg tudom hatarozni az ertekeket - es szerencsere ez most eleg.

• #5224 Apollo17hu őstag Apollo17hu #5214

  Új Válasz 2021-09-03 13:25:02 #5224

  Ú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

  

  Apollo17hu

  őstag

  válasz Apollo17hu #5214 üzenetére

  Többé-kevésbé sikerült összeraknom. Álljon itt az utókornak:

  WITH t AS
 (SELECT t.id
        ,t.ertek
        ,row_number() over(ORDER BY t.id) AS seqnum
  FROM   (SELECT 'A' AS "ID",-2 AS "ERTEK" FROM dual
          UNION ALL
          SELECT 'B',-5 FROM dual
          UNION ALL
          SELECT 'C',-1 FROM dual
          UNION ALL
          SELECT 'D', 3 FROM dual
          UNION ALL
          SELECT 'E',10 FROM dual
          UNION ALL
          SELECT 'F',-7 FROM dual
          UNION ALL
          SELECT 'G',-4 FROM dual
          UNION ALL
          SELECT 'H',20 FROM dual
          UNION ALL
          SELECT 'I',-1 FROM dual
          UNION ALL
          SELECT 'J',-3 FROM dual) t),
cte(id,ertek,runningsum,seqnum) AS
 (SELECT ID
        ,ertek
        ,(CASE
           WHEN ertek > 0 THEN
            0
           ELSE
            ertek
         END) AS runningsum
        ,seqnum
  FROM   t
  WHERE  t.seqnum = 1
  UNION ALL
  SELECT cte.id
        ,t.ertek
        ,(CASE
           WHEN t.ertek + cte.runningsum > 0 THEN
            0
           ELSE
            t.ertek + cte.runningsum
         END) AS runningsum
        ,t.seqnum
  FROM   cte
  JOIN   t
  ON     t.seqnum = cte.seqnum + 1
         /*AND t.id = cte.id*/)
SELECT cte.ertek, cte.runningsum AS korr_ertek
FROM   cte
ORDER  BY seqnum

• #5220 Apollo17hu őstag pch #5217

  Új Válasz 2021-09-03 12:56:07 #5220

  Ú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

  

  Apollo17hu

  őstag

  válasz pch #5217 üzenetére

  nem csak annyi

• #5216 Apollo17hu őstag nyunyu #5215

  Új Válasz 2021-09-03 11:49:49 #5216

  Ú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

  

  Apollo17hu

  őstag

  válasz nyunyu #5215 üzenetére

  Igen, úgy! Próbáltam keresgélni a neten, és mindenhol rekurzív sql-kódokra bukkantam, de nagyon nem sikerül összerakni, hogy működjön.

• #5214 Apollo17hu őstag

  Új Válasz 2021-09-03 11:32:02 #5214

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok!

  Kumulálás témában kérem a segítségetek. Pozitív és negatív egész számaim vannak egy mezőben. Egy másik mezőben azonosító szerepel, a rekordok e mentén vannak rendezve.
  Az a feladat, hogy a számokat kumuláljuk, de a kumulált érték nem lehet magasabb nullánál. Tehát ha az aggregálás "átfordulna" a pozitív tartományba, akkor ott 0-nak kell szerepelnie.

  Így néz ki a modell, amiben a 3. oszlopot kellene létrehoznom:

  ID ERTEK KORR_ERTEK
  A -2 -2
  B -5 -7
  C -1 -8
  D 3 -5
  E 10 0
  F -7 -7
  G -4 -11
  H 20 0
  I -1 -1
  J -3 -4
  
  Sajnos sqlfiddle hibát dob, ezzel próbálkoztam:

  CREATE TABLE proba (
    id varchar2(10),
    ertek number
)
;
INSERT INTO proba
    ([id], [ertek])
VALUES
    ('A',-2),
    ('B',-5),
    ('C',-1),
    ('D',3),
    ('E',10),
    ('F',-7),
    ('G',-4),
    ('H',20),
    ('I',-1),
    ('J',-3)
;

  Milyen módon lehetne kiszámolni a KORR_ERTEK mezőt?

  Maga a kumulálás ezzel működik, de a nullával való korrigálásra nem jöttem rá:
  SUM(ertek) OVER(ORDER BY id)

• #5073 Apollo17hu őstag

  Új Válasz 2021-07-26 19:48:22 #5073

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok! MSSQL-ben hogy tudom kiszurni azokat a rekordokat, amelyek kirxkraxokat tartalmaznak egy mezoben? Tehat a mezob n levo ekezetes karakterek helyett ilyen tokomtudja karakterkeszlet karakterei jelennek meg.
  Probaltam regexp kifejezessel (azAZ), de ugy ertelmezi, mintha ezek a speci karakterek is az abece reszei lennenek. Nincs vmi egyszeru tisztito fuggveny erre?

• #4915 Apollo17hu őstag sztanozs #4914

  Új Válasz 2021-04-14 18:21:14 #4915

  Ú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

  

  Apollo17hu

  őstag

  válasz sztanozs #4914 üzenetére

  a peldaja alapjan sztem kifelejtette azt a konnyitest, hogy a start es end allapotok nem "keresztezik" egymast ket rekordon belul, es igy mar lenyegesen konnyebb (lenne) a feladat

• #4913 Apollo17hu őstag kw3v865 #4910

  Új Válasz 2021-04-14 16:06:17 #4913

  Ú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

  

  Apollo17hu

  őstag

  válasz kw3v865 #4910 üzenetére

  letrehozol egy segedmezot, aminek mondjuk a "range" nevet adod, feltoltod egy case when segitsegevel, es az alapjan groupolsz. ennyi. :)

• #4902 Apollo17hu őstag nyunyu #4901

  Új Válasz 2021-03-31 08:56:25 #4902

  Ú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

  

  Apollo17hu

  őstag

  válasz nyunyu #4901 üzenetére

  Es ha a GROUP BY-ban egy CASE WHEN-t tartalmazo mezore sorszammal hivatkozom, akkor az javit a futasi idon? Mert nehany hsz.-szel feljebb ez hangzott el.

• #4897 Apollo17hu őstag bambano #4896

  Új Válasz 2021-03-26 13:39:15 #4897

  Ú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

  

  Apollo17hu

  őstag

  válasz bambano #4896 üzenetére

  Ugy emlekszem, hogy abban a kornyezetben, ahol korabban dolgoztam, a group by 2 nem mukodott, de igazsag szerint masfel eve nem kodoltam, siman lehet, hogy az is jo lenne.

• #4895 Apollo17hu őstag kw3v865 #4894

  Új Válasz 2021-03-26 13:06:50 #4895

  Ú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

  

  Apollo17hu

  őstag

  válasz kw3v865 #4894 üzenetére

  select sum(value)
  ,case
  when sector = 1 then '1'
  when sector in (2, 3, 4) then '2, 3, 4'
  when sector = 5 then '5'
  end
  from test
  group by
  case
  when sector = 1 then '1'
  when sector in (2, 3, 4) then '2, 3, 4'
  when sector = 5 then '5'
  end

• #4892 Apollo17hu őstag RedHarlow #4890

  Új Válasz 2021-03-19 19:49:07 #4892

  Ú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

  

  Apollo17hu

  őstag

  válasz RedHarlow #4890 üzenetére

  Előbb kell szűrnöd a "B" táblára, és a szűrt "B" táblát kell az "A" táblához kötnöd:

  SELECT a.datum, b.data1, b.data2
FROM a,
(SELECT b.datum, b.data1, b.data2
FROM b
WHERE b.notes = 007) b
WHERE a.datum = b.datum(+);

• #4889 Apollo17hu őstag RedHarlow #4888

  Új Válasz 2021-03-19 16:34:12 #4889

  Ú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

  

  Apollo17hu

  őstag

  válasz RedHarlow #4888 üzenetére

  SELECT a.datum, b.data1, b.data2
FROM a, b
WHERE a.datum = b.datum(+)

• #4885 Apollo17hu őstag cattus #4884

  Új Válasz 2021-03-14 18:30:06 #4885

  Ú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

  

  Apollo17hu

  őstag

  válasz cattus #4884 üzenetére

  #keretlentanacs

  elso korben kipucolnam a kodbol a szintet/szobat, es egy terminust hasznalnek

• #4883 Apollo17hu őstag cattus #4882

  Új Válasz 2021-03-14 16:45:20 #4883

  Ú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

  

  Apollo17hu

  őstag

  válasz cattus #4882 üzenetére

  Van esemény, szobaszám, kezdő és befejezési időpont. Eddig oké. De mi az a szint? Az is egy külön attribútum külön mezőben? Minden mező egy adattáblában van?

  Vmi ilyesmire lesz szükséged, ahonnan a megképzett "sorrend" mezőnek veheted később a minimumát:

  RANK() OVER(PARTITION BY szint ORDER BY kezdo_idopont) AS sorrend
  
  Arra kell figyelni, hogy RANK() esetén több minimum is lehet, ha a sorrendiség nem egyértelmű.

• #4868 Apollo17hu őstag Ferfiu #4867

  Új Válasz 2021-02-08 21:16:01 #4868

  Ú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

  

  Apollo17hu

  őstag

  válasz Ferfiu #4867 üzenetére

  

• #4866 Apollo17hu őstag

  Új Válasz 2021-02-07 23:11:44 #4866

  Ú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

  

  Apollo17hu

  őstag

  Olyan oldalt vagy esetleg egyetemi jegyzetet tudtok, ami viszonylag nehezebb sql-lekérdezési feladatokat/példákat tartalmaz? Elsősorban a táblakapcsolatok, többszörös JOIN-ok, egymásba ágyazások érdekelnének.

• #4858 Apollo17hu őstag picur10 #4857

  Új Válasz 2021-01-25 16:34:33 #4858

  Ú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

  

  Apollo17hu

  őstag

  válasz picur10 #4857 üzenetére

  Hat akkor vagy atmesz az mssql topikba, vagy megkeresed az LPAD fuggveny mssql-beli megfelelojet. ;)

• #4856 Apollo17hu őstag picur10 #4855

  Új Válasz 2021-01-25 15:49:59 #4856

  Ú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

  

  Apollo17hu

  őstag

  válasz picur10 #4855 üzenetére

  SELECT LPAD(ora, 2, '0') || LPAD(perc, 2, '0') FROM tabla;

• #4847 Apollo17hu őstag Kommy #4846

  Új Válasz 2020-12-24 10:59:56 #4847

  Ú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

  

  Apollo17hu

  őstag

  válasz Kommy #4846 üzenetére

  En felvennek egy segedmezot, ami a "vegleges" azonositot tartalmazna. Idokozonkent befrissitenem. Az elv az lenne, hogy a duplikatumokckozul azoknal, amelyekre nincs szukseg, feltoltod.

• #4775 Apollo17hu őstag Pulsar #4774

  Új Válasz 2020-11-16 19:27:01 #4775

  Ú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

  

  Apollo17hu

  őstag

  válasz Pulsar #4774 üzenetére

  Transzponálhatod pl. PIVOT függvénnyel, vagy lekorlátozhatod az eredeti selectet úgy, hogy csak az egyik eredménysort adja vissza, aztán egy másik selectben pedig csak a másik eredménysort. Ha utóbbit választod, akkor mehet rá a Descartes-szorzat:

  SELECT egyik.mezo AS mezo_1, masik.mezo AS mezo_2
FROM (egyik_select) AS egyik, (masik_select) AS masik

• #4668 Apollo17hu őstag Szmeby #4667

  Új Válasz 2020-09-04 12:23:54 #4668

  Ú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

  

  Apollo17hu

  őstag

  válasz Szmeby #4667 üzenetére

  A LEAD függvénnyel olyan oszlop hozható létre, ami egy meglévő mező csoportosított/sorbarendezett értékeit eltolja.
  tm5 megoldásában a halmaz nincs csoportosítva, csak ID alapján sorbarendezve. E szerint az ID és a DATUM mezőket egy rekorddal eltolva képzi meg a next_id és next_datum oszlopokat.

  Alapértelmezettként az eltolás mértéke 1, ekkor elhagyható.
  A LEAD-hez hasonló még a LAG függvény, ahol az eltolás "ellenkező" irányba történik.

• #4578 Apollo17hu őstag user112 #4576

  Új Válasz 2020-05-19 20:12:20 #4578

  Ú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

  

  Apollo17hu

  őstag

  válasz user112 #4576 üzenetére

  Amit valójában keresel, az nem a UNION, hanem a GROUP BY záradék ROLLUP paramétere.

• #4551 Apollo17hu őstag user112 #4550

  Új Válasz 2020-05-07 14:19:34 #4551

  Ú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

  

  Apollo17hu

  őstag

  válasz user112 #4550 üzenetére

  select id
      ,sum(adat1)
      ,sum(adat2)
      ,sum(case when ho=2 then adat3 else 0 end)
      ,sum(case when ho=9 then adat4 else 0 end)

• #4543 Apollo17hu őstag Jim Tonic #4542

  Új Válasz 2020-05-04 11:54:25 #4543

  Ú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

  

  Apollo17hu

  őstag

  válasz Jim Tonic #4542 üzenetére

  ROW_NUMBER() függvénnyel egy lekérdezésen belül meg tudod határozni termékenként a MAX(valid_from) és MIN(valid_to) értéket is.

• #4530 Apollo17hu őstag Jim Tonic #4527

  Új Válasz 2020-04-29 12:31:03 #4530

  Ú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

  

  Apollo17hu

  őstag

  válasz Jim Tonic #4527 üzenetére

  Ezzel eltávolítod a listából a duplákat:

  SELECT termek
      ,ar
      ,kezdo_datum
      ,veg_datum
FROM  (SELECT termek
             ,ar
             ,kezdo_datum
             ,veg_datum
             ,COUNT(*) OVER(PARTITION BY termek, kezdo_datum) dupl
        FROM arlista)
WHERE CASE
          WHEN dupl > 1 AND veg_datum IS NULL
          THEN 0
          ELSE 1
      END = 1

• #4510 Apollo17hu őstag Petya25 #4509

  Új Válasz 2020-04-22 20:41:38 #4510

  Ú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

  

  Apollo17hu

  őstag

  válasz Petya25 #4509 üzenetére

  Fix szélesek az oszlopok, ugye? INSTR(), SUBSTR(), TRIM() jellegű függvényekkel ki tudod mazsolázni belőle mind a 7 mezőt. A SELECT után 7 db függvénykombináció adná ki a 7 db mezőt.

• #4504 Apollo17hu őstag Szmeby #4503

  Új Válasz 2020-04-15 01:10:18 #4504

  Ú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

  

  Apollo17hu

  őstag

  válasz Szmeby #4503 üzenetére

  Bocs, hogy beleszólok, de Lourohoz hasonló munkakörben dolgoztam, és csak megerősíteni tudom:
  - High-level menedzsernek nem fogod tudni elmagyarázni. Nem érdeklik a részletek ilyen mélységben, és nem is akarja megérteni, mert nincs ideje rá. A közvetlen vezetődnek mondhatod, de ő nagyon jól tudja, hogy a nála nagyobb emberek az ilyesmit egyszerűen lesöprik az asztalról. Csak az eredmény számít.
  - A másik dolog pedig az, hogy felsőbb szinten a vezetők hajlamosak (sőt, néha kötelező az előmenetel miatt) rotálni szervezeten belül. Tehát, ha 3-5 évig működik a toldozás-foldozás, akkor nyert ügye van, mert úgyis dobbant máshova.

  ...és ennek analógiájára: az a fejlesztő balek, aki próbál prudensen, hosszú távban gondolkodva végezni a dolgát. Ahhoz képest mindenképp, aki összehányja a munkát, de feleannyi idő alatt eredményt mutat fel, és 2-3 évente munkahelyet vált (aminek következményeként nem kell saját maga után takarítani).

• #4473 Apollo17hu őstag bambano #4472

  Új Válasz 2020-04-04 10:47:49 #4473

  Ú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

  

  Apollo17hu

  őstag

  válasz bambano #4472 üzenetére

  Ez logikajat tekintve ugyanaz, mint amit nyunyu es en leirtunk. Azzal a kulonbseggel, hogy a NOT IN miatt belassulhat, ahogy a calendar tabla bovul.

• #4466 Apollo17hu őstag bambano #4465

  Új Válasz 2020-04-03 10:45:35 #4466

  Ú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

  

  Apollo17hu

  őstag

  válasz bambano #4465 üzenetére

  én meg ingyen sört és örök életet
  de engem is érdekel, hogy lehet egyszerűbben

• #4464 Apollo17hu őstag

  Új Válasz 2020-04-03 10:10:24 #4464

  Ú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

  

  Apollo17hu

  őstag

  Jaaa... Az szívás. Ahol én dolgoztam, ott a calendar tábla minden naptári napot tartalmazott talán 1900-tól 2040-ig. Külön flag volt a munkanapokra, hóvégekre, hét melyik napja, mi a köv. munkanap stb.

  Szóval akkor egy ilyen segédtáblát kellene megképezni, és felhasználni ahhoz, amit fentebb írtam. Legyen mondjuk ez a calendar_2! Valahogy így állítanám elő calendar_2 -t:

  1. Keresnék egy számláló táblát az adatbázisban, ami 0 és egy nagyon nagy szám között tartalmazza az egész számokat. (Ha nincs ilyen, akkor tetszőleges táblán row_number-t képeznék, és azt használnám.)
  2. A számláló tábla rekordjaihoz megképezném a calendar_day mezőt, ami a naptári napokat tartalmazza. Az 1. naptári nap a bemenő dátum, az összes többi pedig ez a dátum növelve a számlálóban lévő értékkel (date_add, ha van ilyen postgresql-ben).
  3. Szintén új mezőben megjelölném a szombatokat és vasárnapokat. (modulo 7 eredménye alapján)
  4. A 2. pontban létrehozott listához gyengén (LEFT JOIN) hozzákötném a calendar táblát, amiben csak a rendkívüli munkarend napjai vannak benne.
  5. A 3. és 4. pontban lévő információ felhasználásával létre lehetne hozni a végleges workday_fl mezőt.

  Így állna elő a calendar_2 halmaz, amiből calendar_day-t és workday_fl-et lehetne felhasználni a megoldáshoz.

• #4462 Apollo17hu őstag bambano #4461

  Új Válasz 2020-04-03 09:20:10 #4462

  Ú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

  

  Apollo17hu

  őstag

  válasz bambano #4461 üzenetére

  Fognám a calendar táblát, raknék rá egy "nagyobb, mint a bemenő dátum" ÉS "legyen munkanap" szűrést, majd a kapott halmazon valamilyen rank() függvénnyel (van ilyen postgresql-ben?) egy sorszám mezőt generálnék, ami dátum szerint növekvő sorrendben osztaná ki a sorszámot. Ahol a sorszám n, az a keresett dátum.

  Ehhez mondjuk az is kell, hogy az ünnepnapokból és a munkanap áthelyezésekből rendelkezésre álljon egy munkanap flag ['I', 'N'] is. Ha ilyen nincs, azt mondjuk egy CASE WHEN-nel külön le kell még kezelni.

• #4429 Apollo17hu őstag

  Új Válasz 2020-02-05 15:30:53 #4429

  Ú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

  

  Apollo17hu

  őstag

  sztem amit irtam, az teljesen jo neki, csak nem vette eszre

• #4424 Apollo17hu őstag BuktaSzaki #4422

  Új Válasz 2020-02-04 15:38:58 #4424

  Ú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

  

  Apollo17hu

  őstag

  válasz BuktaSzaki #4422 üzenetére

  Valahogy igy:
  ...
  WHERE ...
  AND CASE
  WHEN tetel = 'egyik ertek' THEN 1
  WHEN tetel = 'masik ertek' THEN 1
  END = 1
  ...

• #4418 Apollo17hu őstag peterr85 #4417

  Új Válasz 2020-01-23 08:25:52 #4418

  Ú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

  

  Apollo17hu

  őstag

  válasz peterr85 #4417 üzenetére

  még annyit esetleg, hogy intervallumra szűrésnél használhatod a BETWEEN operátort is

• #4400 Apollo17hu őstag BuktaSzaki #4399

  Új Válasz 2020-01-17 12:53:15 #4400

  Ú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

  

  Apollo17hu

  őstag

  válasz BuktaSzaki #4399 üzenetére

  Akkor, amit #4397 -ben írtál, az rendben van. Vagy nem értem. Példák kellenének.

• #4398 Apollo17hu őstag BuktaSzaki #4397

  Új Válasz 2020-01-17 12:34:57 #4398

  Ú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

  

  Apollo17hu

  őstag

  válasz BuktaSzaki #4397 üzenetére

  Pontosan mi a kodod? Nem lehet, hogy vannak olyan szolgaltatasok, amelyek - azon felul, hogy hibasan duplikalva vannak bizonyos szerzodesekhez - tobb szerzodeshez is kapcsolodnak?

• #4396 Apollo17hu őstag BuktaSzaki #4395

  Új Válasz 2020-01-17 10:22:22 #4396

  Ú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

  

  Apollo17hu

  őstag

  válasz BuktaSzaki #4395 üzenetére

  SELECT tabla.szerzszam, tabla.szolgazon
FROM tabla
GROUP BY tabla.szerzszam, tabla.szolgazon
HAVING COUNT(*) > 1

  Ezzel azokat is megkapod, ha 2-nél többször van hozzárendelve ugyanaz a szolgáltatás.

• #4347 Apollo17hu őstag

  Új Válasz 2019-11-18 00:04:08 #4347

  Ú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

  

  Apollo17hu

  őstag

  Igen, fenn van az XE, és egyelőre a célnak megfelel. Köszönöm az eddigi segítséget mindenkinek, jövök még a topikba, ha elakadok.

• #4342 Apollo17hu őstag bpx #4341

  Új Válasz 2019-11-17 12:25:47 #4342

  Ú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

  

  Apollo17hu

  őstag

  válasz bpx #4341 üzenetére

  Guglizás közben olvastam a container és a pluggable database-ről, de - ahogy írod is - fogalmam sem volt, hogy lehetne normálisan beállítani.

  Nincs Linux ismeretem. Akkor azt mondod, hogyha XE helyett EE-t rakom fel, sokkal egyszerűbben hozzáférek majd a sample schema-khoz? Éjjel már ott tartottam, hogy a zippelt HR-sémát githubról töltöm le, csak az importálásnál megint falakba ütköztem.

• #4340 Apollo17hu őstag updog #4339

  Új Válasz 2019-11-16 23:51:02 #4340

  Ú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

  

  Apollo17hu

  őstag

  válasz updog #4339 üzenetére

  Azért ez eléggé nem volt triviális, hogy először system-ként kell csatlakozni, majd azzal létrehozni egy felhasználót magamnak.

  Rögtön két problémába is ütköztem: először nem engedett felhasználót létrehozni, mert valami prefix (C##) gondja volt. Erre ki kellett adnom egy ALTER SESSION utasítást, és így már lefutott a CREATE USER. Viszont azt sem tudtam, hogy ennek a felhasználónak külön dba jogokat is kell adnom, hogy csatlakozni tudjak vele. Most már szerencsére ez is rendben van.

  Következő lépésként felkutatom a HR sémát, és utánajárok, hogy lehet felrakni, mert egyelőre ezzel is meg vagyok lőve.

• #4338 Apollo17hu őstag

  Új Válasz 2019-11-16 22:51:03 #4338

  Ú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

  

  Apollo17hu

  őstag

  Letöltöttem és telepítettem az Oracle XE-t. Eddig tényleg egyszerű volt. Néztem a tutorialban, hogy próbaként csatlakozni kéne a szerverhez. Ez sokadjára, de összejött a SYSTEM userrel. Mi a különbség SYS, SYSTEM és PDADMIN között? Van még ezeken kívül olyan user, amivel csatlakozni lehet? (újat még nem hoztam létre) Valami olyasmit is olvastam, hogy a Windows useremnek automatikusan létrehoz egy Oracle felhasználót, de azzal nem tudtam belépni.

  Következő lépés az SQL Developer letöltése és beállítása, és onnantól már van egy barátságos környezetem, amiben mókolhatok?

• #4335 Apollo17hu őstag

  Új Válasz 2019-11-16 18:46:38 #4335

  Ú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

  

  Apollo17hu

  őstag

  Otthoni PC-re (Win10) milyen megoldást ajánlanátok, ha szeretnék egy saját adatbázist üzemeltetni? Egyelőre csak létrehoznék néhány táblát, amiket feltöltenék adatokkal, és lekérdezéseket írogatnék.

  Melóban eddig Oracle adatbázissal dolgoztam PL/SQL Developer környezetben, de úgy láttam, hogy ezeknek legfeljebb 1 hónapos trial verziója érhető el.
  Semmilyen tapasztalatom nincs szerver telepítésében, oktatóvideók linkjét is szívesen fogadom.

• #4310 Apollo17hu őstag elBrigi #4309

  Új Válasz 2019-09-23 16:00:32 #4310

  Ú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

  

  Apollo17hu

  őstag

  válasz elBrigi #4309 üzenetére

  Szerintem a CHANGE az egy foglalt (reserved) kifejezés. Próbálj meg más nevet adni neki.

• #4289 Apollo17hu őstag

  Új Válasz 2019-09-04 11:53:04 #4289

  Ú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

  

  Apollo17hu

  őstag

  Ha a lekerdezes WHERE zaradekaban szursz a kivalasztott hozzavalokra, az nem jo?

• #4285 Apollo17hu őstag bandi0000 #4284

  Új Válasz 2019-09-04 09:18:25 #4285

  Ú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

  

  Apollo17hu

  őstag

  válasz bandi0000 #4284 üzenetére

  SELECT DISTINCT t1.mezo_ami_kell
  FROM egyik_tabla t1, masik_tabla t2, kapcsolo_tabla rel
  WHERE t1.kapcsolo_mezo_t1 = rel.kapcsolo_mezo_t1
  AND rel.kapcsolo_mezo_t2 = t2.kapcsolo_mezo_t2

• #4248 Apollo17hu őstag Agony #4247

  Új Válasz 2019-08-12 11:21:04 #4248

  Ú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

  

  Apollo17hu

  őstag

  válasz Agony #4247 üzenetére

  Szia! Oracle-ben, ha ket idopontot kivonsz egymasbol, akkor a napok szamat kapod kulonbsegkent tizedes szamkent. Ha minden feladat vegdatumabol kivonod a kezdo datumat, es osszeadod oket, akkor napokban kapod meg a kivant erteket. Ezt mar csak 1.440-nel (24*60) kell felszoroznod.

• #4180 Apollo17hu őstag bambano #4179

  Új Válasz 2019-06-14 13:16:26 #4180

  Ú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

  

  Apollo17hu

  őstag

  válasz bambano #4179 üzenetére

  Nem, vagyis én próbálok mindig a legjobb tudásom szerint kódolni, de mezei kontrollerként nem értek az optimalizáláshoz. Egyébként azt a 20 darab allekérdezést össze tudnám gyúrni 5-6-ba, de akkor egy potenciális jövőbeli hibakeresés sokkal tovább tartana (nekem is, de méginkább olyasvalakinek, aki nem ismeri a kódot). Az én szemszögemből az lenne a legegyszerűbb, ha egy táblából tudnék leszedni mindent, de a mostani mókolás is azért kellett, mert nincs IT erőforrás a fejlesztésekre.

  Szerencsére nem mind a 20 allekérdezés 800 soros, összesen "csak" 4.300 sorból áll a kód.

• #4178 Apollo17hu őstag Apollo17hu #4174

  Új Válasz 2019-06-14 10:15:15 #4178

  Ú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

  

  Apollo17hu

  őstag

  válasz Apollo17hu #4174 üzenetére

  Kollégámmal közösen megoldottuk.

  Volt egy sanda gyanúm, hogy az új allekérdezéseken belül kell keresni a hibát, és beigazolódott. Ezek az új allekérdezések egyenként kb. 800 sornyi programkódból állnak, rengeteg tábla és allekérdezés alkotja őket. Van egy nagyobb saját sémás tábla is, ami csak kiegészítő adatot tartalmaz. Ezt kommenteztem ki, és lefutott a teljes kód. Ezzel az infóval kollégám egy egyszerű use_hash hintet rakott oda, ahova kellett, és így a saját sémás táblával együtt is 4 percen belül fut a teljes kód.

  Az a fura, hogy amíg a 800 soros allekérdezéseket külön-külön futtattuk, nem "borult meg" a végrehajtásuk, viszont a teljes kódban már igen.

• #4174 Apollo17hu őstag bambano #4171

  Új Válasz 2019-06-13 15:01:25 #4174

  Ú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

  

  Apollo17hu

  őstag

  válasz bambano #4171 üzenetére

  Volt korábban ugyanezzel a kóddal memóriaprobléma, de az egyértelmű volt, mert 15 perc után hibaüzenettel leállt. Szerencsére rájöttünk az okára (kb. az volt, hogy a 20 allekérdezés miatt 3^20 szorzót kapott a memóriában elfoglalt mérete, de extra kötésekkel, ezt áthidaltuk).

  Temp tábla sajnos nem játszik. Maga a keretrendszer úgy néz ki, hogy különálló sql-eket tárolunk, amelyeket egy alkalmazás minden nap meghív, lefuttat, az eredményt pedig Excelbe másolja. Nincs lehetőség egymásra épülő kódrészletek megadására.

  @bpx: Jogos, fejből írtam, de élesben jó helyre raktam a hintet. Ezt a materialize-t még kipróbálom, mert tényleg annyira lenne csak szükség, hogy külön-külön meglegyen az allekérdezések eredménye, utána már 2 másodperc alatt kiszámolja.

• #4170 Apollo17hu őstag Ispy #4168

  Új Válasz 2019-06-13 12:58:02 #4170

  Ú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

  

  Apollo17hu

  őstag

  válasz Ispy #4168 üzenetére

  Az a gond, hogy nem végtáblában van szükségem az eredményre, mert egy automatizmus a további feldolgozás során használja.

  @bpx: Próbálkoztam a NO_MERGE hinttel, de egyelőre sikertelenül.

  A kód egyébként kb. így néz ki:

  WITH
t1 as (...),
t2 as (...),
...
t20 as (...)

SELECT ...
FROM /*+ no_merge (t1 t2 ... t20) */
t1,
t2,
...,
t20,
() as tx
WHERE
tx.mezo = t1.mezo(+) AND
tx.mezo = t2.mezo(+) AND
...
tx.mezo = t20.mezo(+)

  Próbáltam LEFT JOIN szintaxisra is átírni a (+) kötéseket, de az sem segített.
  A WITH-del lehet probléma? Azt olvastam, hogy még segít is az optimizer-nek, mert a legtöbb esetben előbb külön-külön számítja ki a WITH-ben lévő allekérdezések eredményét, és csak utána használja őket.

  Hogy érthető legyen: mondjuk t3-at, t7-et és t8-at cseréltem ki. Külön-külön minden t tábla minimális idő alatt lefut, néhányszáz sort eredményeznek. Ha csak t3-at (vagy csak t7-et vagy csak t8-at) cserélem ki, akkor 1 perc alatt lefut a kód. Ha már két táblát is kicserélek, akkor nem.
  Sőt, ha lebutítom így a kódot:

  WITH
t3 as (...),
t7 as (...)

SELECT ...
FROM
t3,
t7,
() as tx
WHERE
tx.mezo = t3.mezo(+) AND
tx.mezo = t7.mezo(+)

  már ez sem fut le. Tehát a 3 új allekérdezés valahogy "összeakad", pedig <1 perc a futási idejük külön-külön.

• #4167 Apollo17hu őstag

  Új Válasz 2019-06-13 08:14:24 #4167

  Ú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

  

  Apollo17hu

  őstag

  Nagy altalanossagban van megoldas (hinteles?) arra, ha van pl. 20 db allekerdezesem, ami egyenkent 200-300 rekordot ad vissza, kulon-kulon 1-60 masodpercig fut, de ha osszekotom oket (a megfelelo mezok menten), akkor elszall az egesz, es egy ora alatt sem fut le. Konkretan van egy ilyen, 5 percen belul futo monstre kodom, aminel 3 allekerdezest lecsereltem, es ez tortent vele. Sajnos plant nem tudok olvasni, ezert altalaban lenne jo vmi tipp, hogy merre induljak el.
  Koszi!

• #4137 Apollo17hu őstag SUPREME7 #4136

  Új Válasz 2019-05-14 07:09:51 #4137

  Ú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

  

  Apollo17hu

  őstag

  válasz SUPREME7 #4136 üzenetére

  LEFT JOIN nyertesek
  ...
  WHERE nyertesek.resztvevo IS NULL

  Tehat az elso ket tabla halmazabol csak azokat a rekordokat tartod meg, amik nem szerepelnek a 3. tablaban.

• #4128 Apollo17hu őstag I02S3F #4127

  Új Válasz 2019-05-11 13:47:38 #4128

  Ú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

  

  Apollo17hu

  őstag

  válasz I02S3F #4127 üzenetére

  Így van. A kódban viszont felesleges mindkét lakosságra vonatkozó mezőt (t1.lakossag, t2.lakossag) felsorolni, mert ugyanaz az értékük.

• #4125 Apollo17hu őstag kw3v865 #4122

  Új Válasz 2019-05-09 14:26:20 #4125

  Ú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

  

  Apollo17hu

  őstag

  válasz kw3v865 #4122 üzenetére

  Így?

  SELECT tabla.mezo
,substr(tabla.mezo, instr(tabla.mezo, '"ref"=>""') + length('"ref"=>""')) relevans_adattartalom
FROM (SELECT 'asfasf saf"ref"=>""ez kell' mezo
FROM dual
UNION
SELECT 'asfasf ssadfalksijdfkeefaf "ref"=>""ez is kell, de ez hosszabb' mezo
FROM dual) tabla

  Substr utolsó paraméterét elhagyva a mező utolsó karakteréig mindent leválogat. Ha nem jó, akkor mindenképp kell egy ismérv/logika, ami meghatározza a releváns karaktersorozat végét.

• #4123 Apollo17hu őstag kw3v865 #4121

  Új Válasz 2019-05-09 10:41:36 #4123

  Ú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

  

  Apollo17hu

  őstag

  válasz kw3v865 #4121 üzenetére

  Ha van PostgreSQL-ben, akkor az Instr() fuggvennyel keresd meg, hol kezdodik a relevans karaktersorozat, es ezt be tudod agyazni egy Substr() fuggveny parametereibe.

• #4114 Apollo17hu őstag kezdosql #4112

  Új Válasz 2019-05-01 14:20:49 #4114

  Ú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

  

  Apollo17hu

  őstag

  válasz kezdosql #4112 üzenetére

  Mindkét megoldásnak van létjogosultsága. A te verziód akkor lenne használható, ha minden egyes napra generálnál egy rekordot, ami a napra vonatkozó aktuális állapotot mutatja. Intervallumok használatával viszont egy csomó erőforrást megspórolsz. Csak akkor van szükség új rekordra, ha valamelyik mező adattartalmában változás történik.

• #4100 Apollo17hu őstag user112 #4096

  Új Válasz 2019-04-17 15:48:25 #4100

  Ú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

  

  Apollo17hu

  őstag

  válasz user112 #4096 üzenetére

  'a', 'b', 'c'... ezek csak példák akartak lenni az azonosítókra, ugyanígy a 20 és a 30 a példarekord számlálója és nevezője

• #4095 Apollo17hu őstag kezdosql #4093

  Új Válasz 2019-04-17 13:48:28 #4095

  Ú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

  

  Apollo17hu

  őstag

  válasz kezdosql #4093 üzenetére

  Nyilvan te is elegedett lettel volna, ha mar az elso kerdesednel azt a reakciot kapod, hogy 'Hogy lehet ilyen hulyeseget kerdezni?'.

  Kiszalltam.

• #4092 Apollo17hu őstag user112 #4091

  Új Válasz 2019-04-17 11:36:16 #4092

  Ú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

  

  Apollo17hu

  őstag

  válasz user112 #4091 üzenetére

  Ez a két módszer:

  SELECT t.azon
,t.c1
,t.c2
,CASE
WHEN t.c2 ! = 0 THEN
t.c1 / t.c2
END AS arany
,CASE
WHEN t.c1 > 10 AND CASE
WHEN t.c2 ! = 0 THEN
t.c1 / t.c2
END > 50 THEN
'x'
END hiba
FROM (SELECT 'a' azon
,20 c1
,30 c2
FROM dual
UNION
SELECT 'b' azon
,20 c1
,0 c2
FROM dual
UNION
SELECT 'c' azon
,40 c1
,NULL c2
FROM dual
UNION
SELECT 'd' azon
,500 c1
,3 c2
FROM dual) t

  SELECT u.*
,CASE
WHEN u.c1 > 10 AND u.arany > 50 THEN
'x'
END hiba
FROM (SELECT t.azon
,t.c1
,t.c2
,CASE
WHEN t.c2 ! = 0 THEN
t.c1 / t.c2
END AS arany
FROM (SELECT 'a' azon
,20 c1
,30 c2
FROM dual
UNION
SELECT 'b' azon
,20 c1
,0 c2
FROM dual
UNION
SELECT 'c' azon
,40 c1
,NULL c2
FROM dual
UNION
SELECT 'd' azon
,500 c1
,3 c2
FROM dual) t) u

• #4090 Apollo17hu őstag user112 #4089

  Új Válasz 2019-04-17 09:10:14 #4090

  Ú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

  

  Apollo17hu

  őstag

  válasz user112 #4089 üzenetére

  Bele tudod agyazni az arany case when-jet egy masik case when-be. Vagy fogod a lekerdezesed, allekerdezesbe rakod, es ennek az allekerdezesenek az arany mezojere szinten tudsz hivatkozni.

  Ha osztassal generalsz uj mezot, akkor tanacsos kivetelkezelest is alkalmazni a nullaval valo osztas hibalehetosegenek elkerulese erdekeben.

• #4088 Apollo17hu őstag kezdosql #4086

  Új Válasz 2019-04-16 17:03:46 #4088

  Ú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

  

  Apollo17hu

  őstag

  válasz kezdosql #4086 üzenetére

  Azert a marhasag kifejezes eleg eros. Az eddigi hsz.-eid alapjan igenyelted a ravezetest, en pedig ezt tettem.

• #4069 Apollo17hu őstag kezdosql #4068

  Új Válasz 2019-04-14 16:37:36 #4069

  Ú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

  

  Apollo17hu

  őstag

  válasz kezdosql #4068 üzenetére

  Csinálhatod azt is, hogy mindent, de mindent egyetlen táblában tárolsz.

  Esemény dátuma, szezon, esemény megnevezése, eseményhez kapcsolódó játékos, játékos csapata, játékos lábmérete stb. Minden rekord rengeteg attribútumot (mezőt) tartalmazna, de az adattáblára írt lekérdezések az elvárthoz képest sokkal lassabban futnának, mert a tábla nem lenne normalizált.

  Normalizáláshoz adatmodellt kellene kialakítani, ami viszont nem ott kezdődik, hogy az egyes mezőknek megmondjuk az adattípusát. Hanem megnézzük, hogy az ismétlődő értékek közül melyeket lehet dimenziótáblában tárolni. Ilyenek pl.: [dátumok] tábla, [csapatok] tábla, [játékosok] tábla, és ezek kapcsolódhatnának a ténytábláddal, amiben ezekre a táblákra csak hivatkozol, nem tárolod a bennük lévő összes mezőt.

• #4064 Apollo17hu őstag kezdosql #4063

  Új Válasz 2019-04-06 13:39:03 #4064

  Ú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

  

  Apollo17hu

  őstag

  válasz kezdosql #4063 üzenetére

  Csinalhatnal egy calendar tablat, amiben felveszed az osszes datumot. Teszel bele egy mezot, ami megmutatja, hogy az adott naptari nap melyik szezon.

  Es lenne a tenytablad, amiben a konkrrt esemenyeket rogzited datumokkal. Ha rogzitettel egy esemenyt, akkor az esemeny datuma menten a calendar tablabol megtudod, hogy melyik szezont erinti.

• #4045 Apollo17hu őstag kw3v865 #4040

  Új Válasz 2019-03-02 00:06:26 #4045

  Ú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

  

  Apollo17hu

  őstag

  válasz kw3v865 #4040 üzenetére

  Azt szabad tudni, hogy milyen probléma vezetett odáig, hogy erre keresed a megoldást?

• #3699 Apollo17hu őstag mr.nagy #3698

  Új Válasz 2018-02-14 23:31:42 #3699

  Ú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

  

  Apollo17hu

  őstag

  válasz mr.nagy #3698 üzenetére

  Szia!

  Írtam a példádhoz egy favágó kódot. Legalábbis ha sql-ben kellene megoldani, akkor én úgy állnék neki, hogy meghatároznám a total igényt, az igénylők darabszámát, és ebből számolnék tovább.

  Akkor nincs gond, ha az igény többszöröse a kiosztható értéknek, mert akkor egyszerűen a kiosztható értéket az igénylők számával kell leosztani, és minden igénylő ennyit fog kapni. (Ezt már nem kódoltam bele, de értelemszerűen 20 db CASE WHEN-ről lesz szó...)

  Eddig írtam meg a kódot. Még megképeztem egy olyan mezőt, ami azt tartalmazza, hogy mennyi olyan kiosztható érték marad, amiből már csak 1-1 darabot lehet véletlenszerűen (vagy extra logikával?) odaadni az igénylőknek.

  select case when alap.kioszthato >= alap.total then 'N' else 'I' end hiany_fl
,case when alap.kioszthato >= alap.total then null
when isnull(alap.darab, 0) = 0 then null
else floor(alap.kioszthato / alap.darab) end ennyire_kell_csokkenteni
,case when alap.kioszthato >= alap.total then 0
when isnull(alap.darab, 0) = 0 then null
else alap.kioszthato - floor(alap.kioszthato / alap.darab) * alap.darab end ennyi_szetosztando_marad
,alap.*
from
(SELECT P1+P2+P3+P4+P5+P6+P7+P8+P9+P10+P11+P12+P13+P14+P15+P16+P17+P18+P19+P20 as total
,case when P1= 0 then 0 else 1 end + case when P2= 0 then 0 else 1 end + case when P3= 0 then 0 else 1 end + case when P4= 0 then 0 else 1 end + case when P5= 0 then 0 else 1 end + case when P6= 0 then 0 else 1 end + case when P7= 0 then 0 else 1 end + case when P8= 0 then 0 else 1 end + case when P9= 0 then 0 else 1 end + case when P10= 0 then 0 else 1 end + case when P11= 0 then 0 else 1 end + case when P12= 0 then 0 else 1 end + case when P13= 0 then 0 else 1 end + case when P14= 0 then 0 else 1 end + case when P15= 0 then 0 else 1 end + case when P16= 0 then 0 else 1 end + case when P17= 0 then 0 else 1 end + case when P18= 0 then 0 else 1 end + case when P19= 0 then 0 else 1 end + case when P20= 0 then 0 else 1 end as darab
,t.*
FROM Teszts t) alap

• #3686 Apollo17hu őstag kw3v865 #3684

  Új Válasz 2018-02-01 22:08:12 #3686

  Ú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

  

  Apollo17hu

  őstag

  válasz kw3v865 #3684 üzenetére

  Nincs időm elmélyedni benne, de nem az lenne az egyszerű megoldás, ha hisztogramkészítés előtt az 5.000 rekordból kiszűrnéd azokat, ahol nincs érték?

• #3671 Apollo17hu őstag Fundiego #3670

  Új Válasz 2018-01-19 22:00:38 #3671

  Ú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

  

  Apollo17hu

  őstag

  válasz Fundiego #3670 üzenetére

  listagg()
  de vannak más megoldások is

• #3643 Apollo17hu őstag BeeGee2115 #3642

  Új Válasz 2017-12-25 00:10:59 #3643

  Ú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

  

  Apollo17hu

  őstag

  válasz BeeGee2115 #3642 üzenetére

  - tran.tranzakcio_ertek helyett - nvl(tran.tranzakcio_ertek, 0) -t használj, és így nem fog "eltűnni" az egyenleg

  szerk.: Most olvasom, hogy közben magad is rájöttél a megoldásra.

• #3641 Apollo17hu őstag BeeGee2115 #3640

  Új Válasz 2017-12-24 23:06:55 #3641

  Ú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

  

  Apollo17hu

  őstag

  válasz BeeGee2115 #3640 üzenetére

  kb. úgy, ahogy az előbb leírtam: a kettőből 1-1 allekérdezést csinálsz, és számlaszám mentén összekötöd őket, ill. a számlára aggregált allekérdezéshez "gyengén" kötöd a tranzakcióra aggregált allekérdezést (LEFT JOIN, ha a pluszjeles szintaktika nem működne)

• #3639 Apollo17hu őstag BeeGee2115 #3638

  Új Válasz 2017-12-24 22:46:46 #3639

  Ú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

  

  Apollo17hu

  őstag

  válasz BeeGee2115 #3638 üzenetére

  Egy mintaadatbázis jól jönne sqlfiddle-ben. Addig is ezt értettem meg a leírtakból:

  SELECT
szla.Számla,
szla.szamla_ertek - tran.tranzakcio_ertek
FROM
(SELECT Számla,
SUM(Összeg) AS szamla_ertek
FROM Adatok
GROUP BY Számla) szla
,(SELECT Tranzakció,
SUM(Összeg) AS tranzakcio_ertek
FROM Adatok
GROUP BY Tranzakció) tran
WHERE szla.Számla = tran.Tranzakció(+)

  Az lenne az elve, hogy külön-külön összesítjük a "Számla" és a "Tranzakció" mezőkben lévő összegeket, és ahol a "Számla" és a "Tranzakció" egyezik, ott a kettőt kivonjuk egymásból.

• #3637 Apollo17hu őstag BeeGee2115 #3636

  Új Válasz 2017-12-24 22:01:34 #3637

  Ú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

  

  Apollo17hu

  őstag

  válasz BeeGee2115 #3636 üzenetére

  nem vagyok teljesen képben, de talán erre van szükséged:

  SELECT szamla,
SUM(osszeg) - SUM(CASE WHEN tranzakcio IS NOT NULL then osszeg ELSE 0 END)
FROM adatok
GROUP BY szamla

  ...ami - ha jól gondolom - egyenértékű ezzel (egyszerűen eldobjuk azokat a rekordokat, amelyek tranzakciót - is - jelölnek):

  SELECT szamla,
SUM(osszeg)
FROM adatok
WHERE tranzakcio IS NULL
GROUP BY szamla

• #3635 Apollo17hu őstag BeeGee2115 #3634

  Új Válasz 2017-12-24 16:07:25 #3635

  Ú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

  

  Apollo17hu

  őstag

  válasz BeeGee2115 #3634 üzenetére

  Így?

  SELECT szamla,
SUM(CASE WHEN osszeg > 0 then osszeg ELSE 0 END) pozitiv,
SUM(CASE WHEN osszeg < 0 then osszeg ELSE 0 END) negativ
FROM adatok
GROUP BY szamla

• #3568 Apollo17hu őstag Fundiego #3567

  Új Válasz 2017-10-01 15:36:05 #3568

  Ú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

  

  Apollo17hu

  őstag

  válasz Fundiego #3567 üzenetére

  Szélsőséges esetben előfordulhat olyan holtverseny is, ahol két versenyző az összes sportágat tekintve azonos helyezésekkel rendelkezik. Ekkor csak pénzfeldobás (--> random szám generálás) dönthet. Vagy létrehozol egy külön táblát, amiben a fair-play értékeket vezeted.

  Visszatérve a problémádhoz talán megoldás lehetne, ha játékosonként a játékosok helyezéseit sorbarendezve, összefűzve letárolnád, és ennek a minimumát vennéd a helyezések minimuma helyett. Pl.:

  egyik játékos helyezései:

  1, 2, 2, 4, 5, 5, 5 --> 1224555

  másik játékos helyezései:

  1, 2, 3, 3, 3, 3, 3 --> 1233333

  Oracle-ben ehhez a listagg() függvényt tudod használni. Valahogy így:

  listagg(helyezes) WITHIN GROUP (ORDER BY helyezes) OVER (PARTITION BY jatekos)

• #3551 Apollo17hu őstag Fundiego #3550

  Új Válasz 2017-09-01 23:22:51 #3551

  Ú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

  

  Apollo17hu

  őstag

  válasz Fundiego #3550 üzenetére

  Valami nagyon nem jó az adatbázisod kialakításában.
  Martonx fórumtárs szokta javasolni, hogy egy mintát tölts fel sqlfiddle-re, mert így nem tudunk segíteni.

• #3541 Apollo17hu őstag Fundiego #3539

  Új Válasz 2017-08-26 23:23:37 #3541

  Ú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

  

  Apollo17hu

  őstag

  válasz Fundiego #3539 üzenetére

  Én sem teljesen értem a problémádat, de ahol NOT IN operátort használsz, ott a "szallitas" mezőt célszerű nlv() függvénybe tenni, mert a nullértékek boríthatják a logikádat.

• #3451 Apollo17hu őstag tm5 #3448

  Új Válasz 2017-06-15 18:49:38 #3451

  Ú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

  

  Apollo17hu

  őstag

  válasz tm5 #3448 üzenetére

  Szia!

  Meg fogom nézni, hogy van-e lehetőség ilyen formára átírni. Igazából a két allekérdezésre úgy tekintettem, mintha logikailag "különállóak" lennének. Eddig úgy gondoltam, hogy a kód futása külön-külön megy végbe allekérdezéseken belül, és csak ezt követi a részeredmények összekapcsolása. Szándékosan így is írtam a legtöbb kódot, beszédes alias-t adva az allekérdezéseknek, hogy pl. hibakereséskor könnyebben értelmezhesse akár egy olyan személy is, aki először találkozik vele. Ezek szerint nagyon nem így működik...

• #3450 Apollo17hu őstag

  Új Válasz 2017-06-15 14:56:45 #3450

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok!

  Még nem volt időm minden választ megnézni, viszont -Zeratul- megoldása tökéletes (<1 sec lett a futási idő). Köszönöm szépen! Később részletesen is átnézem, hogy tanuljak belőle.

• #3445 Apollo17hu őstag bpx #3443

  Új Válasz 2017-06-14 20:50:48 #3445

  Ú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

  

  Apollo17hu

  őstag

  válasz bpx #3443 üzenetére

  PL/SQL Developer 9.x-ről álltunk át a napokban 12-es verzióra. Valószínűleg ez lehet a probléma forrása (talán az üzemeltetés nem hangolta tökéletesre az adatbázis szervert?).

  Plant nem tudok mutatni, a lekérdezés egyébként kb. így néz ki:

  SELECT t1.mezo_1
,t1.mezo_2
FROM (SELECT t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
,(SELECT t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
WHERE t1.id = t2.id

  Ez futott korábban 1 másodpercig, most meg 5-10 perc között. t1 és t2 allekérdezés is 200-300 eredménysort ad vissza (mindkettő dimenziótábla), külön-külön 1 másodpercen belül most is lefutnak. Mindkét táblában az id egyedi, szám formátumú.

  Az a vicces, hogyha t1 allekérdezésben találomra kikommentezek egy szűrőfeltételt (az eredménysorok száma 10-15%-kal nő), akkor az egész lekérdezés ismét 1 másodpercen belül fut.

  Legalapabb hintekkel próbálkoztam (use_hash, use_nl stb.), de igazából nem tudom, mikor mit kell használni. Tapasztalatból csak annyi van meg, hogy nagyméretű ténytáblák kötésénél 90%-ban csökkenti a futási időt a use_hash hint.

  Tudom, hogy ez még mindig kevés, és hogy jobban kellene specifikálni a problémát, de a hét végére valószínűleg kapok segítséget munkatársaktól, tehát mindenképp meg fog oldódni a probléma, csak azt hittem, vannak általánosan alkalmazható hintelések.

• #3442 Apollo17hu őstag sztanozs #3441

  Új Válasz 2017-06-14 17:23:30 #3442

  Ú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

  

  Apollo17hu

  őstag

  válasz sztanozs #3441 üzenetére

  Mindkét lekérdezés eredményében szám típusú egyedi azonosító van, ezekkel kötök. Megpróbálok munkatársaknál is körbekérdezni. Ha van eredmény, jelzem itt is. (elég bosszantó)

• #3440 Apollo17hu őstag

  Új Válasz 2017-06-14 12:59:16 #3440

  Ú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

  

  Apollo17hu

  őstag

  Sziasztok!

  Van két, 1 másodpercen belül futó lekérdezésem (néhány száz rekord). A kettő eredményét összekötve 5 percre növekszik a futási idő. Milyen hintet érdemes használnom?

• #3433 Apollo17hu őstag

  Új Válasz 2017-06-09 15:42:58 #3433

  Ú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

  

  Apollo17hu

  őstag

  Egy rövid topikösszefoglalóra lenne szükség, amiben egy link mutat az sql fiddle -re.

• #3423 Apollo17hu őstag GreenIT #3422

  Új Válasz 2017-05-30 19:01:37 #3423

  Ú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

  

  Apollo17hu

  őstag

  válasz GreenIT #3422 üzenetére

  Az új tábla valahogy így nézhetne ki:

  CEG_CIMEK: ceg_kod, szekhely_fl, cim, kezdo_datum, bef_datum

  A szekhely_fl jelölné, hogy székhelyről ('I') vagy telephelyről ('N') van-e szó.
  A cim mezőt megbonthatod további mezőkre (orszag, telepules, iranyitoszam stb.).

  Ha egy rekordban kell megjelenítened a cég adott napra lekért összes telephelyét, akkor arra pl. a LISTAGG függvényt lehet használni.

• #3421 Apollo17hu őstag Dilikutya #3418

  Új Válasz 2017-05-26 23:32:18 #3421

  Ú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

  

  Apollo17hu

  őstag

  válasz Dilikutya #3418 üzenetére

  Szerintem nem jó a táblaszerkezeted. Ez a "nagyon sok" mező "ki van forgatva", pedig meg lehetne oldani az egészet két mezővel: az egyik értéke a mostani mezőnév lehetne, a másik értéke pedig az, amire most is szűrsz.

  Most így vannak az adataid:

  [mező_1] | [mező_2] | [mező_3] | [mező_4] | [mező_5] | ... | [mező_n]
  ---------------------------------------------------------------------------------------------
  'AA' 'BB' 'XX' 'YY' 'PP' 'MM' 'ZZ'
  'ee' 'zz' 'bb' 'NN' 'PP' 'MM' 'ww'
  'dd' 'UU' 'CC' 'tt' 'xx' 'AA' 'WW'

  helyette viszont lehetnének így is:

  [mező_1] | [mező_2]
  ------------------------------
  'mező_1' 'AA'
  'mező_1' 'ee'
  'mező_1' 'dd'
  'mező_2' 'BB'
  'mező_2' 'zz'
  'mező_2' 'UU'
  ...
  'mező_n' 'ZZ'
  'mező_n' 'ww'
  'mező_n' 'WW'

• #3255 Apollo17hu őstag kezdosql #3254

  Új Válasz 2017-01-09 19:50:59 #3255

  Ú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

  

  Apollo17hu

  őstag

  válasz kezdosql #3254 üzenetére

  Az csv (comma separated value) akar lenni, nem?

• #3147 Apollo17hu őstag #30734848 #3142

  Új Válasz 2016-07-26 18:56:45 #3147

  Ú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

  

  Apollo17hu

  őstag

  válasz #30734848 #3142 üzenetére

  Regexp függvényekkel próbálkozz.

• #3132 Apollo17hu őstag Louro #3131

  Új Válasz 2016-07-22 18:43:14 #3132

  Ú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

  

  Apollo17hu

  őstag

  válasz Louro #3131 üzenetére

  Úgy is csinálhattad volna, hogy

  CASE
WHEN
1=1 AND 2=2 AND 3=3 AND 4=4 AND 5=5 THEN 1
WHEN
1=1 AND 2=2 AND 3=3 AND ... THEN ...
END

  és akkor nem kell egymásba ágyaznod őket.

• #3113 Apollo17hu őstag Novics #3112

  Új Válasz 2016-06-29 19:03:18 #3113

  Ú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

  

  Apollo17hu

  őstag

  válasz Novics #3112 üzenetére

  esetleg SUBSTR(id, 4)

• #3095 Apollo17hu őstag tm5 #3094

  Új Válasz 2016-06-03 18:47:59 #3095

  Ú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

  

  Apollo17hu

  őstag

  válasz tm5 #3094 üzenetére

  vagy:

  rank() over(ORDER BY egyikmezo) as sorrend

  a külső lekérdezés WHERE feltételében pedig:

  AND sorrend = 1

• #3061 Apollo17hu őstag Louro #3059

  Új Válasz 2016-05-06 02:02:18 #3061

  Ú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

  

  Apollo17hu

  őstag

  válasz Louro #3059 üzenetére

  Szerintem ketté kellene szedni az "azon" mezőt. Ha egyben marad, le kell vágni az első karaktert, és a mentén csoportosítani. Nem tudom ellenőrizni, hogy szintaktikailag helyes-e, de valahogy így nézne ki a sorszámozás:

  SELECT rendeles.azon
  ,substr(rendeles.azon, 1, 1) ||
  rank() over(PARTITION BY substr(rendeles.azon, 1, 1) ORDER BY rendeles.azon) +
  CASE WHEN substr(rendeles.azon, 1, 1) = 'K'
  THEN max_sorszam.max_k
  WHEN substr(rendeles.azon, 1, 1) = 'L'
  THEN max_sorszam.max_l
  WHEN substr(rendeles.azon, 1, 1) = 'M'
  THEN max_sorszam.max_m
  END uj_azon
  FROM rendeles
  ,(SELECT MAX(CASE WHEN substr(sorszam.azon,1, 1) = 'K'
  THEN to_number(substr(sorszam.azon, 2)) END) AS max_k
  ,MAX(CASE WHEN substr(sorszam.azon,1, 1) = 'L'
  THEN to_number(substr(sorszam.azon, 2)) END) AS max_l
  ,MAX(CASE WHEN substr(sorszam.azon,1, 1) = 'M'
  THEN to_number(substr(sorszam.azon, 2)) END) AS max_m
  FROM sorszam) max_sorszam

• #3021 Apollo17hu őstag Memphis #3020

  Új Válasz 2016-03-19 01:18:34 #3021

  Ú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

  

  Apollo17hu

  őstag

  válasz Memphis #3020 üzenetére

  Excelben is lehet olyan felületet kialakítani, hogy a mezei user észre sem veszi, hogy Office-alkalmazásban van. Kell hozzá egy pofás template, űrlapismeretek, kis makrózás, és egyáltalán nem munkafüzetként fogsz tekinteni a fájlra. Persze egy ilyet normálisan megcsinálni napokba telik (bármilyen környezetben).

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