A linkelt oldalon, ha bármivel bővíteni akarod az adatbázist:
Semmi baj. Marad a lokális adatbázis és abban garázdálkodom.
A linkelt oldalon, ha bármivel bővíteni akarod az adatbázist:
Semmi baj. Marad a lokális adatbázis és abban garázdálkodom.
Köszi, ez nekem is probléma volt
JBL Synthesis -> Egy hangrendszer mind fölött, egy hang kegyetlen, egy a nyomorba dönt ( árával biztos), bilincs az Egyetlen
Sziasztok!
Segítségetek kérném. TSQL.
Tábla:
Ceg | Adoszam | Datum | Rel
Egy céghez több adószám tartozik a táblában, de cégenként a legkésőbbi dátumot kellene kiválasztani, és ott Rel értékét 1-re állítani
Köszi.
Alcohol & calculus don't mix. Never drink & derive.
SELECT ceg, adoszam, datum
FROM
(SELECT ceg, adoszam, datum,
ROW_NUMBER() OVER (PARTITTION BY ceg ORDER BY datum DESC) rnum
FROM Table) x
WHERE rnum = 1
UPDATE T -- nem emlékszem, hogy kell-e ide az alias
SET Ref = 1
FROM Tabla T
JOIN (SELECT ceg, adoszam, datum
FROM
(SELECT ceg, adoszam, datum,
ROW_NUMBER() OVER (PARTITTION BY ceg ORDER BY datum DESC) rnum
FROM Table) x
WHERE rnum = 1 ) jo ON T.ceg = jo.ceg AND T.adoszam = jo.adoszam AND t.datum = jo.datum
Némileg egyszerübb lenne a JOIN ha lenne egy ID oszlopa is a táblának.
Van ilyen update szintaxis? *
Szerettek veszélyesen élni.
Én inkább szabvány merge-et írnék:MERGE INTO Tabla t
USING (SELECT ceg, adoszam, datum,
ROW_NUMBER() OVER (PARTITION BY ceg ORDER BY datum DESC) rnum
FROM Tabla) x
ON (t.ceg = x.ceg
AND t.adoszam = x.adoszam
AND t.datum = x.datum)
WHEN MATCHED THEN
UPDATE SET t.Rel = CASE WHEN x.rnum = 1 THEN 1 ELSE 0 END;
(Gondolom a régebbi adószámokat egyúttal rel=0-ra kell állítani.)
* Ja tényleg, SQL Server 2008 környékén próbálták elcsaklizni a Teradata ügyfeleit, aztán emiatt implementálták a Teradata tuningolt update szintaxisát a FROM clause-zal.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Nem nagyon használom én se, csak van néhány kollégám akik rá vannak függve.
És igen ha ilyen kell akkor én is a MERGE-öt szoktam. Csak akkor amikor ez a kérdés felpattant pont egy ilyen csináltunk a melóban.
Ha már veszélyesen élés akkor, hadd említsem az Updateable viewk tömkelegét INSTEAD OF triggerekkel. A fél ház (WS backend) ezen lóg.
éppen most ért el engem is az a kérdés, hogy updatelek valamit, ha a subquery több soros
a stacken sem találtam egyszerű megoldást, szerencsére van korábban megírt sql query gyűjteményem, és abban találtam az IN-t (hülyülök el, tudom)
UPDATE vmi
SET
a = 1
WHERE id IN
(SELECT id...
dátum szerint rendezd sorba visszafelé, és csak 1 értéket szedj ki (LIMIT 1)
Ezzel az a baj, hogy csak 1 fix értékre tudsz állítani, olyat nem tudsz így, hogy egy másik tábla vagy egy lekérdezés eredményétől függjenek a frissítendő oszlopok.
Hello IT! Have you tried turning it off and on again?
Köszönöm mindkettőtöknek.
Alcohol & calculus don't mix. Never drink & derive.
Sziasztok!
Egy kis segítséget szeretnék kérni.
Van egy tábla dbo.Ajandek néven
Benne sok oszlop.
De ebből nekem ami lényeg, az a tétel, netto, brutto
Minden tétel 2 tipusból áll, így 2 rekordot rögzít.
1 200 250
1 100 125
2 500 600
2 50 75
És így tovább. Létre akarok hozni egy nézetet, amiben ezek egyesítve vannak tételenként 1 sorba. Azt mivel tudom megadni? SUM-al 2 oszlop értékét tudom összeadni, de mi adja össze soronként, ha az ID egyezik?
If you chase two rabbits you will lose them both.
select sum(...) group by tetel;
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Akkor a saját fejemben már túlbonyolítottam ezt az egészet.
If you chase two rabbits you will lose them both.
create view v_ajandek as
select tetel, sum(netto) sum_netto, sum(brutto) sum_brutto
from dbo.Ajandek
group by tetel;
Lényeg az, hogy minden a group by-ban nem megadott oszlopra valamilyen aggregáló függvényt (min, max, count, sum, avg...) kell használni, esetedben mindkét oszlopra külön-külön szummázol.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
LEFT JOIN nem működik a mariadb-nél, vagy én nézek be valamit?
Szóval 5 táblából kell összevadászni az adatokat.
Van a számlák tábla, benne a számla ID-vel, a partner ID-vel, partnernév, bruttó.
Van a bank tábla, ebben a bank id és dátuma most a releváns.
Van a bank tétel, ebben a bank id, brutto, szamla id az érdekes.
Van a pénztár tábla. itt pénztar id és dátum kell.
Van a pénztár tétel, ebben a pénztár id és számla id kell.
Kellenek azok a számlák amik a megadott nap és előtte nem lettek fizetve.
Amivel próbálkoztam:
SELECT t1.szamla_id, t1.vevo_id, t1.vnev, t1.brutto, ROUND(IFNULL((SUM(t2.bevetel)-(t2.kiadas)),0),2) AS bank, ROUND(IFNULL((SUM(t4.bevetel)-(t4.kiadas)),0),2) AS penztar
FROM kimszamla AS t1
LEFT JOIN banklista AS t2 ON t2.szamla_id=t1.szamla_id
LEFT JOIN bank AS t3 ON t3.bank_id=t2.bank_id
LEFT JOIN penztarlista AS t4 ON t4.szamla_id=t1.szamla_id
LEFT JOIN penztar AS t5 ON t5.penztar_id=t4.penztar_id
WHERE t1.tipus='0'
AND t1.teljesites <= '2023-01-01'
AND t3.datum <= '2023-01-01'
AND t5.datum <= '2023-01-01'
AND t2.kivezetes = 'V_SZ'
AND t4.kivezetes = 'V_SZ'
AND bank+penztar<>brutto
GROUP BY t1.szamla_id
ORDER BY t1.vevo_id ASC
Viszont csak 2 partnert gyűjt ki. Amik nincsenek benne a pénztár/bank táblába azokat nem.
A left join-nak nem az a lényege, hogy az induló táblából az összes adat ott legyen?
[ Szerkesztve ]
http://sb-soft.hu - "A" számlázó
Nem fordítva írod?
select * from T1
left join T2 on T1.azon=T2.azon
ami az egyenlet bal oldalán van (T1) abból minden és T2-ből az egyező.
ha
left join T2 on T2.azon=T1.azon
akkor minden T2-ből és T1-ből ami egyező
tehát nem mindegy mi van az egyenlet bal oldalán, az lesz a "minden"
Elvileg igazad van, viszont továbbra se jó, mert ha nincs a t2-be akkor nem szerepel a listába
http://sb-soft.hu - "A" számlázó
Most már ennyire átírtam, hogy a pénztár s bank táblákat összejoin-oltam és azt tettem left joinba. De az eredmény ugyanaz..
SELECT t1.szamla_id, t1.vevo_id, t1.vnev, t1.brutto, (ROUND(IFNULL((SUM(t2.bevetel)-(t2.kiadas)),0),2)+ROUND(IFNULL((SUM(t4.bevetel)-(t4.kiadas)),0),2)) as fizetve
FROM kimszamla AS t1
LEFT JOIN (banklista AS t2,bank AS t3) ON (t1.szamla_id=t2.szamla_id AND t2.bank_id=t3.bank_id)
LEFT JOIN (penztarlista AS t4,penztar AS t5) ON (t1.szamla_id=t4.szamla_id AND t4.penztar_id=t5.penztar_id)
WHERE t1.tipus='0'
AND t1.teljesites <= '2023-12-01'
AND t3.datum <= '2023-12-01'
AND t5.datum <= '2023-12-01'
AND t2.kivezetes = 'V_SZ'
AND t4.kivezetes = 'V_SZ'
GROUP BY t1.vevo_id;
Mintha lesz@rna left join vagy right join van inner join lenne. Az eredmény mindig ugyanaz
http://sb-soft.hu - "A" számlázó
Megoldva.
Túlgondoltam, és az elejétől nem jó volt az elképzelés.
Megoldás, hogy a bank és pénztár adatokat union-al összekötöttem majd ezt a selectet joinoltam a számlához.
Hiába, este már aludni kel.
http://sb-soft.hu - "A" számlázó
WHERE t1.tipus='0'
AND t1.teljesites <= '2023-01-01'
AND t3.datum <= '2023-01-01'
Wherehez írt feltételek erős szűrési feltételek.
Ha nincs t3-ból találat, akkor a t3.datum <='2023-01-01' ki fogja szűrni az egész t1 sorát, mintha erős join lenne.
Próbáld meg áttenni a left joinolt táblákra vonatkozó feltételeket a left join ON-ja után:LEFT JOIN bank AS t3 ON t3.bank_id=t2.bank_id AND t3.datum <= '2023-01-01'
Where mögött csak az eredeti táblára, és hozzá erősen joinoltakra vonatkozó feltételek maradjanak.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Nem fordítva írod?
select * from T1
left join T2 on T1.azon=T2.azon
ami az egyenlet bal oldalán van (T1) abból minden és T2-ből az egyező.
Elvileg a kettő ekvivalens, aztán onnantól kódolási stílus kérdése/hitvita, hogy azt a táblát írjuk előre, amelyiket akarjuk joinolni (T2) a korábbiakhoz (T1), vagy amelyikhez joinoljuk (T1) az újat (T2)
Amit benézhetett az az, hogy az SQL-92 szabvány előtti Oracle join szintaxisban a Where mögött explicite jelölni kellett, hogy melyik oldalnál megengedett a null, és ha arra az aliasra voltak extra feltételek, akkor ott is:FROM kimszamla AS t1, banklista AS t2, bank AS t3
WHERE t1.tipus='0'
AND t1.teljesites <= '2023-01-01'
AND t2.szamla_id (+) = t1.szamla_id
AND t3.bank_id (+) = t2.bank_id
AND t3.datum (+) <= '2023-01-01'
(Tradícionálisan itt írták előre a régi táblát aztán az egyelőség után az újat a (+)-szal, az jelölte a left joint, fenti példában right joinnak látszik.)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Jobban végignéztem a query elejét.
Egyszer a select által visszaadott oszloplistában létrehozol egy bank meg egy penztar oszlop aliast
Lejjebb meg hivatkozol egy bank meg egy penztar nevű táblára, amiket elneveztél t2 meg t4-nek.
Nem szerencsés egy queryn belül ugyanolyan aliast definiálni, mint amilyen táblát/aliast használsz máshol.
Hello IT! Have you tried turning it off and on again?
A macska rúgja meg, igazad van. Szerintem ezt nekem rosszul magyarázták és azért maradt meg így, de nem az egyenlet oldala határozza meg, hanem a select utáni sorrend (pongyolán fogalmazva).
Előbb-utóbb megjegyzem.
Következőn agyalok: leveleket írok. A levelekben van egy csomó határidő, 8 nap, 15 nap, stb. Jobb lenne az X nap határidő helyett konkrét dátumot írni. Szabály szerint hétvégén és ünnepnapon csúszik a határidő. Van egy táblám (én mindig postgresql ) :
id: bigserial, datum: date, stb...
Ha egy nap hétfő,...,péntek, ÉS nincs benne a táblában, akkor munkanap.
tehát konkrét dátumhoz és nap darabszámhoz kellene a dátum, ami annyi munkanappal később van.
valaki akar egy ilyen sql lekérdezésen agyalni?
előre is kösz.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Szerintem azt a táblát ügyesebben is használhatnád. Előre gyárthatnál egy intervallum listát dátum tól-ig, amikhez bejegyzed, hogy abban az intervallumban az eredeti határidőt X-re át kell írnod (tovább tolod). Ha nem találtál olyan tábla sort, marad a régi. Ha akár perc pontosan akarsz számolni, akkor naponta egy sor, ami éves viszonylatban még mindig csak 365 sor. Nem a világ vége.
>valaki akar egy ilyen sql lekérdezésen agyalni?
A lekérdezést nem írom meg helyetted, a lusta mindenit
>előre is kösz.
you welcome
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
Értem, tehát csináljak egy háromdimenziós táblát, amire az összes napra az összes lehetséges lekérdezési napra és határidőre beleírom, hogy hány nap???
Most vagy nem értettem, amit írtál, vagy nem ez lesz a csapásirány...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Nálunk ez úgy van megoldva, hogy van egy days tábla, amibe kolléga minden decemberben feltölti előre a következő évi dátumokat, meg mellé, hogy hanyadik napja a hétnek.
Ha valami ünnepnap, akkor 1-7 helyett 8 értéke van, ha meg munkanap áthelyezéses szombat, akkor 5 (péntek) lesz az értéke
Ezt használva az x. napot követő első munkanap lekérdezés úgy alakulna, hogy megnézed, hogy a kérdéses dátum+x. nap után melyik a legkisebb olyan nap, aminek 1-5 közötti az értéke.
Ha meg x. munkanap kell, akkor a kérdéses dátumnál nagyobbak közül sorbarakod az 1-5 közötti értékűeket, aztán ebből veszed az x. legkisebbet.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Melyik határidőt? Ez így azért nem jó, mert az, hogy egy határidős nap esetén mennyi a korrekció, függ attól, hogy előtte mikor mennyi munkanap volt. Tehát ha pl. pünkösd hétfő jön ki, akkor attól függően, hogy húsvét előtt vagy után kérdeztem le, más korrekció kell.
Nem elég egyszer feltölteni, mert az, hogy mi munkanap, folyamatosan változhat.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
akkor fejlesztenetek kell szerintem ez sem jó.
például idén dec. 20-án ki akarok adni egy 15 napos határidőt, kijön január 4, szombat, lépek tovább, január 6. hétfő az első munkanap.
Csak közben volt egy 6 napos karácsony meg egy szilveszter, és ez így pont 4 munkanap lesz.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
x. munkanap:select actdate
from (
select d.actdate, row_number() over (order by actdate asc) rn
from days d
where d.actdate > to_date('2024-12-20','yyyy-mm-dd')
and d.dateid in (1,2,3,4,5) --munkanap
)
where rn = 15;
-- 2025-01-17 00:00:00
(actdate a dátum mező, dateid-ben van tárolva az 1-7 hétfő-vasárnap, 0 ünnep)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
más szám jön ki, ha egy korábbi napon keresel hosszabb határidőt, mint ha egy későbbi dátumon keresel rövidebb határidőt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
ez volt az eredeti kérdés summázata:
"tehát konkrét dátumhoz és nap darabszámhoz kellene a dátum, ami annyi munkanappal később van."
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Oracle szerint így jönnek a munkanapok dec. 20 péntek után:
Ha ez sem jó, akkor nem értem, mit szeretnél.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
>Nem elég egyszer feltölteni, mert az, hogy mi munkanap, folyamatosan változhat.
HR portálon előző év végén már ott a lista következő évre. Elvileg nem kellene túl nagy ügynek lennie, hogy írsz egy függvényt, aminek tömbösen behajigálod azokat az adatokat, és az legyártja neked a korrekciós táblát. Évente 1x kicsi manuális pepecselés, de ha ennyitől kizökkensz, add ki diákmunka cégeknek
Eltérő ünnepnap halmozódások.
Ha jól értettem, hosszú határidők vannak, és menet közben több ünnepnap, hétvége, olyasmi tud közbe jönni, és az a problémád, hogy olyankor eltérő korrekció kell. Nos, ha legalább a határidők folyton azonos hosszúságúak, az induló napból egy korrekciós tábla meg tudja neked adni a határidő lejártát. Mert azt előre kiszámolod. Ha eltérő határidők léteznek, mint 8,15,23,32 nap és társai, részint csinálhatsz minden határidő típusra külön táblát, részint csinálhatod azt, hogy tábla elemek helyére egy json stringet raksz be, ami attól a naptól kezdve az összes határidő típusra ad egy kimenetet, és a string lekérdezése után a json-t parsingolod, aztán felhasználod. A json belefér 1 táblába, de kissé N1NF. Ha szebben akarod, az több tábla lesz, és az lesz "csúnyább"
Ha adatkezeléssel foglalkozol, nem baj, ha nem akadsz ki azon, hogy gyártani kell pár táblát, amit fel is kell töltened. Vagy ha annyitól kiakadsz, és látni sem bírod az adatkezelést, inkább bízd azt a részét másra. Amit nem látsz, az nem fáj
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
Ne bonyolítsuk ennyire túl, hogy korrekciós tábla, meg json parseolás.
Munkanap tábla karbantartása az max 1 óra/év.
Legalábbis annyi idő alatt dobtam össze DBFiddlében, úgy, hogy ágyban a hasamon a laptoppal pötyögök 2 ujjal, és gugliznom kellett a postgre szintaxisát.
Mondjuk arra nem jövök rá, mi a baja a határidő függvényemmel, mert a fordításkori hibaüzenet nem túl beszédes, de biztosan valami triviális szintaxist néztem be, csak Oraclehoz szokott szemmel nem tűnik fel.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
"Ha adatkezeléssel foglalkozol, nem baj, ha nem akadsz ki azon, hogy gyártani kell pár táblát, amit fel is kell töltened.": ha adatkezeléssel foglalkozol, nem baj, ha nem csinálsz felesleges munkát magadnak.
2. Ha adatkezeléssel foglalkozol, akkor a redundáns adattárolástól üvöltve menekülsz.
Szerk: nem csak az a nap marad ki, amit a hr portálon közölnek. Az is kimarad, ami helyi okokból nem munkanap vagy nem teljesértékű munkanap. Pl. egy rakás cégnél karácsony és szilveszter között takarékon vannak.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
ez második ránézésre jó eredmény, csak mostanra aludtam is a két ránézés között.
de, szerintem, messze nem optimális.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Aludtam rá egyet, és leesett, hogy tényleg ostoba vagyok
Felesleges annyit előre gyorsítani. Van lekérdezési rekord limit. Elég csak a munkanapokat egyesével bejegyezni a hr oldal alapján, aztán X1 dátumtól kezdve kérni X2 (vagy X2+1) rekordot, és a legutolsóból kivenni a dátumot. És arra még azt se mondhatja senki, hogy kinézetre csúnya.
@bambano
>Szerk: nem csak az a nap marad ki, amit a hr portálon közölnek. Az is kimarad, ami helyi okokból nem munkanap vagy nem teljesértékű munkanap. Pl. egy rakás cégnél karácsony és szilveszter között takarékon vannak.
A számítógépet logikus dolgokra lehet programozni. Előre nem ismerhető szeszélyek meghatározására nem alkalmas.
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
Ja, ha multikulti környezetben akarod ezt használni, akkor kell még egy oszlop a days táblába, ahova felveszed az országot/tartományt, aztán a függvénybe/querybe azt a feltételt is beleteszed, hogy melyik ország/tartomány munkanapjait számolja.
De akkor lehet szívni az olyan különbségekkel, mint pl. araboknál péntek-szombat a hétvége, tehát arab országoknál a vasárnap lesz az 1, csütörtök az 5 a táblában.
Meg külön-külön összevadászni+felvinni a helyi ünnepeket...
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Van lekérdezési rekord limit. Elég csak a munkanapokat egyesével bejegyezni a hr oldal alapján, aztán X1 dátumtól kezdve kérni X2 (vagy X2+1) rekordot, és a legutolsóból kivenni a dátumot. És arra még azt se mondhatja senki, hogy kinézetre csúnya.
Ezért tettem a belső selectbe a row_number()-t, hogy számozza be a találatokat, aztán a külső selectbe meg az rn = 15 feltételt.
Felesleges az egész naptárat visszaadni a frontendnek, ha úgyis csak 1 dátumra van szüksége belőle.
Hello IT! Have you tried turning it off and on again?
"A számítógépet logikus dolgokra lehet programozni. Előre nem ismerhető szeszélyek meghatározására nem alkalmas.": próbáljunk meg az sql témakörben maradni.
Az algoritmus abszolút egyszerű: van egy tábla az adatbázisban, ahova a főnök beírja azokat a napokat, amikor valamiért nem az alapértelmezett nyitvatartás van. Ezt törvény szerint 60 nappal előre kell megoldani, tehát nem mindig írják bele egy évre előre. A szabály annyi, hogy ha ebben a táblában van az adott dátumra rendkívüli nyitvatartás bejegyezve, akkor az nem munkanap. Minek bonyolítsam. Amikor naptár szerint hétfő-péntek munkanap és nincs rekord arra a dátumra, az munkanap.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Akkor legenerálod helyben az adott dátumnál nagyobb hétköznapokat, ebből a halmazból kivonod (minus vagy left outer join) a főnököd dátumait, aztán abból keresed x. legkisebb értéket.
De ezzel nem oldottad meg a szombati munkanapok kérdését.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
"Akkor legenerálod helyben ... x. legkisebb értéket.": de, ezzel mindent megoldottam.
Kösz a segítséget.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Oracleben gyorsan összedobva:
with munkanap as (
select a.*
from (
select to_date('2023-12-31','yyyy-mm-dd') + rownum as actdate, to_char(to_date('2022-12-31','yyyy-mm-dd') + rownum, 'd') as dateid
from (
select rownum r
from dual
connect by rownum <= 5000)
) a
left join days d
on d.actdate = a.actdate
and d.dateid = 0
where a.dateid in (1,2,3,4,5)
and d.actdate is null)
select actdate
from (
select m.*, row_number() over (order by actdate asc) rn
from munkanap m
where m.actdate > to_date('2024-12-20','yyyy-mm-dd')) x
where rn = 15;
Ahogy néztem reggel, Postgre szintaxissal sokkal egyszerűbb lenne a munkanap CTE.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?