Zapytanie dotyczące różnicy dat

Dzien dobry wszystkim, mam problem z zapytaniem tsql. W tabeli praca znajdują się kolumny startdate i enddate. Chciałabym obliczyć różnice między tymi datami w godzinach, ale uwzględniając tylko dni robocze. czy ktoś mógłby mi coś podpowiedzieć? Dodam jeszcze że różnica w datach może wynosić ponad tydzień. Pozdrawiam

Dni robocze w jakim kraju i dla jakiego typu umowy? Czy może chcesz uciąć tylko weekendy? https://stackoverflow.com/questions/252519/count-work-days-between-two-dates

Dni robocze w Polsce dla umowy o pracę

Nie napiszesz w SQL systemu kadrowego. Daremne. Para pójdzie w gwizdek.

Wcześniej czy później i tak zaczniesz to robić prawidłowo, w kodzie

To bardzo ciekawe :) Trzeba będzie uwzględnić święta ruchome i pozostaje problem zakresu - w niektórych latach jest przejście, kiedy dzień był pracujący a następnego roku już było wolne. Przykład, który robi to po części dobrze: https://www.altkomakademia.pl/baza-wiedzy/qna/discussion/591/w-jaki-sposob-obliczyc-ilosc-dni-roboczych/p1 ale i tak mi wychodzi, że trzeba będzie załatwić to kodując.

W SQLu można zrobić, ale nie zawsze jest sens.

1. Dni wolne utrzymujesz w tabeli: DNI_WOLNE - dane referencyjne/konfiguracja (może się zmieniać w czasie)

2. Na wejściu dostajesz dwie daty: startDate i endDate

a) Generujesz zbiór pomocniczy (może to być CTE, albo subequery) np. DNI_W_OKRESIE_WEJSCIOWYM

startDate
startDate+1

...
endDate

Taki zbiór można wygenerować zapytaniem rekursywnym.

b) Wyznaczasz różnicę zbiorów: DNI_W_OKRESIE_WEJSCIOWYM - DNI_WOLNE

np.

• Robisz LEFT JOINA od DNI_W_OKRESIE_WEJSCIOWYM do DNI_WOLNE po dacie i odfiltrowujesz rekordy, dla których znalazłeś dopasowanie w DNI_WOLNE , albo
• Robisz różnicę zbiorów: DNI_W_OKRESIE_WEJSCIOWYM EXCEPT DNI_WOLNE, albo
• Korzystasz ze skorelowanej klauzuli WHERE NOT EXISTS (wybierz te rekordy z DNI_W_OKRESIE_WJSCIOWYM dla których nie istnieje rekord w DNI_WOLNE)

Pewnie można inne implementacje w SQLu wymyślać.

Możesz też nie generować zbioru pomocniczego, tylko wówczas będziesz szedł w procedury / logikę poza bazą.

Jak liczyć godziny? To będzie już szczegół. Z Twojego opisu nie wiadomo, czy chodzi Ci o zegarowe czy w jakichś umownych godzinach (np. otwarte od 8 do 18) i tylko w takich godzinach liczysz.

ZrobieDobrze napisał(a):

Nie napiszesz w SQL systemu kadrowego. Daremne. Para pójdzie w gwizdek.

Wcześniej czy później i tak zaczniesz to robić prawidłowo, w kodzie

Wszystko się da napisać w SQLu. W wielu przypadkach będzie to mniej wydajne, trudniejsze w utrzymaniu, albo i niewygodne, ale nie pisz ludziom, że togo nie zrobią, bo odpowiedzą "potrzymaj mi piwo". Utrzymuję aplikację, której cała logika biznesowa mieści się w bazie (nawet zapytania do poszczególnych okien zapisane są w bazie). Może nie jest to kadrówka, ale też nie prosty system rezerwacji biletów. I nie ma mowy, żeby coś się nie dało (jak ktoś kiedyś wymyślił taki system, to teraz trzeba go utrzymywać i realizować potrzeby. Jak trzeba, to trzeba.

Liczenie dni roboczych z uwzględnieniem dni wolnych od pracy jest jak najbardziej realne. Oczywiście wymaga, jak już zostało wspomniane, ustalenia kalendarza świąt ruchomych i nieruchomych, ale jeśli będziemy to liczyć "w kodzie", to też musimy taki kalendarz stworzyć. A czy zapiszemy go w bazie, czy w kodzie, to już kwestia możliwości, potrzeb i upodobań.

Policz różnicę absolutną w timestamp, policz różnicę dni wolnych (świąt ruchomych, nieruchomych, dodanych i usuniętych) a później odejmij.

Fac napisał(a):

Wszystko się da napisać w SQLu. W wielu przypadkach będzie to mniej wydajne, trudniejsze w utrzymaniu, albo...

Liczenie dni roboczych z uwzględnieniem dni wolnych od pracy jest jak najbardziej realne. Oczywiście wymaga, jak już zostało wspomniane, ustalenia kalendarza świąt ruchomych i nieruchomych, ale jeśli będziemy to liczyć "w kodzie", to też musimy taki kalendarz stworzyć. A czy zapiszemy go w bazie, czy w kodzie, to już kwestia możliwości, potrzeb i upodobań.

Tak / nie / zalezy. W sensie literalnym rozumiem co mówisz (plus @yarel ).
Dawno temu pracowałem w / przy ekosystemie z takim rozwiązaniem

I przychodzi dzień ... bum ! , i mamy ludzi w kaledarzu siedmiodniowym (zanikło, ale sie mówiło "jak palacze" - mowa o palaczach w kotłowni ,a nie papierosów). (w drugim poście kol próbuje dopowiedzieć "wg umowy o pracę", czyli zdradza jeszcze niedojrzałą, ale dobrym kierunku intuicję ... )

W kodzie odziedziczysz / zaimplementujesz interfejs ICalendar, ssie dane w zuuupełnie innych części systemu, a na pewno nie z tabel o oficjalnych kalendarzach
W SQL złożoność kwerendy rośnie trzykrotnie, a tylko po to by najczęściej zwracała puste zestawy wierszy