Dodawanie rekordów do bazy - cyklicznie

Witam,

Podczas pisania aplikacji stanąłem na takim problemie. A mianowicie potrzebuję dodać do bazy do jednej tabeli rekordy. Chcę tutaj przechowywać jaka osoba którego dnia ma zmianę w firmie. Zmian jest 4. Pracują po 12h (dzień, noc). Zmiany odbywają się cyklicznie czyli jestem w stanie powiedzieć kto będzie miał zmianę np 18 lutego w dzień (nie biorąc pod uwagę ewentualnych zwolnień itp.). Chciałbym te informacje przechowywać w bazie, by później w aplikacji móc pobierać i sprawdzić kto ma zmianę któregoś tam dnia w przód.

Czy dodawanie do bazy tylu rekordów w przód (np. pół roku) ma jakiś sens? Jeśli tak to w jaki sposób mogę dodać te rekordy za pomocą jakiegoś algorytmu czy coś? Bo ręczne wklepywanie mija się z celem. Czy może jest jakiś inny ciekawy sposób na zrealizowanie tego?

Pozdrawiam

XardasLord napisał(a):

jestem w stanie powiedzieć kto będzie miał zmianę np 18 lutego w dzień

to jest właśnie ten algorytm do tego

w jaki sposób mogę dodać te rekordy za pomocą jakiegoś algorytmu czy coś?

Czy dodawanie do bazy tylu rekordów w przód (np. pół roku) ma jakiś sens?

wg mnie nie ma. Lepiej w bazie trzymać warunki brzegowe - kto od kiedy do kiedy pracuje i jak startuje jego pierwsza zmiana aby można było z tego wyliczyć jaką zmianę w dany dzień będzie miał. Jeśli z jakiegoś powodu się zmieni to trzeba wystartować nowy schemat. Dodatkowo wszystkie wyjątki jak np.

(nie biorąc pod uwagę ewentualnych zwolnień itp.).

Czyli rozumiem, że najlepiej zapisać w bazie jeden cykl zmian (np. od 1 stycznia dzień do 4 stycznia noc, bo później znów się kolejność powtarza) i później po stronie aplikacji, bądź też serwera na podstawie algorytmu wyliczać zmiany w przyszłości?

dokładnie takie jest moje zdanie. Bo inaczej masz zamiar co np. pół roku dodawać na najbliższe pół roku wpisy. Trochę to takie niebardzo :). Dodatkowo jak zmieni się model pracy (np. z 3-zmianowego na 4-zmianowy) to tylko zmieniasz algorytm i zaznaczasz od kiedy ma obowiązywać a dane takie jak urlopy czy L4 pozostają bez zmian. A jakbyś miał wypełnione na ileśtam do przodu to trzeba zmieniać.

Co innego gdyby te dane wpadały do bazy na bieżąco - pracownik wchodzi do pracy i odbija kartę i przy wyjściu tak samo - ale wtedy to są faktyczne dane a nie wyliczane

abrakadaber napisał(a):

Co innego gdyby te dane wpadały do bazy na bieżąco - pracownik wchodzi do pracy i odbija kartę i przy wyjściu tak samo - ale wtedy to są faktyczne dane a nie wyliczane

Tutaj właśnie to nie dotyczy tego :) Rzeczywiście wpisując tylko jeden cykl i na podstawie algorytmu wyliczając jest to można powiedzieć 'zautomatyzowane' i pewne zmiany w planach wiążą się tylko z modyfikacją algorytmu na serwerze, a nie po stronie aplikacji klienckiej. Fajna sprawa, o to mi właśnie chodziło :) Teraz tylko napisać dość dobrze algorytm i zobaczymy co z tego wyjdzie ;) Dzięki!

EDIT:

Ale tak sobie myślę teraz, że im dalej w las, czyli załóżmy minie pół roku, a dane w tabeli będą cały czas ze stycznia to żeby dokopać się do np lipca to przez kilka miesięcy ten algorytm będzie musiał się przekopać i będzie działał coraz wolniej. Po roku jeszcze bardziej, itd. Chyba będę musiał wtedy modyfikować te dane startowe z bazy na nieco bardziej zbliżone do teraźniejszości co jakiś czas?

XardasLord napisał(a):

Ale tak sobie myślę teraz, że im dalej w las, czyli załóżmy minie pół roku, a dane w tabeli będą cały czas ze stycznia to żeby dokopać się do np lipca to przez kilka miesięcy ten algorytm będzie musiał się przekopać i będzie działał coraz wolniej. Po roku jeszcze bardziej, itd. Chyba będę musiał wtedy modyfikować te dane startowe z bazy na nieco bardziej zbliżone do teraźniejszości co jakiś czas?

Ale co Ty tam chcesz kopać?

W bazie powinieneś trzymać dwie struktury:

1. Typowy cykl (nie wiem, czy to tydzień czy dwa, czy 10 dni, nieważne) z datą początkową i kolejnością w jakiej pracują kolejni pracownicy.
2. Wyjątki od cyklu, czyli data, godzina (czy tam id zmiany) i id pracownika, który faktycznie pracował w danym momencie.

Jeśli chcesz obliczyć, kto powinien pracować pojutrze, to pobierasz strukturę typowego cyklu, a algorytm odejmuje daty i oblicza kto powinien pracować. To zadziała tak samo szybko dla dowolnej daty w przyszłości.

Jeśli chcesz obliczyć, kto pracował jakiegoś dnia w przeszłości, to najpierw sprawdzasz w tabeli wyjątków, jeśli coś tam jest, to zwracasz wynik. A jeśli nic tam nie ma, to pobierasz typowy cykl i tym samym algorytmem wyznaczasz kto pracował. To zadziała tak samo szybko dla dowolnej daty w przeszłości.