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 ]

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.

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.

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 ]

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.

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

Oracle szerint így jönnek a munkanapok dec. 20 péntek után:

Ha ez sem jó, akkor nem értem, mit szeretnél.

[ Szerkesztve ]

>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 ]

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

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.

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 ]

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.

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

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 ]

"Akkor legenerálod helyben ... x. legkisebb értéket.": de, ezzel mindent megoldottam.

Kösz a segítséget.

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 ]