Struktura tabeli pod planowanie godzin pracy pracowników

Posiadam tabelę z agregowanymi do 1 godziny wartościami sprzedaży. Wygląda mniej więcej tak:

[datetime], [id_sklepu], [id_typuDnia],  [wartość_1] ... [wartość_X]

jest ich mniej więcej 16 mln wierszy, Wszystkie pochodzą z agregacji paragonów, z okresu około półtora roku.
Do niedawna było to wystarczające.

Obecnie muszę dołożyć nowy zestaw danych, dotyczący planowanych godzin pracy pracowników. W teorii idealnie pasuje do powyższej tabeli
wystarczy dodać konkretne wartości na końcu wiersza.
Jednak w obecnej tabeli nie mam pełnego szeregu czasowego 24 godzin na dobę. Sprzedaż to zdarzenie losowe występujące w godzinach otwarcia sklepu, praca zaś rozpoczyna się i kończy sporo przed otwarciem i za zamknięciem.
plany pracy pracowników mam w układzie
[id_sklepu], [id_typuDnia] , [ilośćRBh_1] ... [ilośćRBh_X] - typ dnia to konkretny dzień tygodnia, lub inny ważny handlowo dzień (np tłusty czwartek) jest ich w sumie ze 40
więc tych danych jest sporo mniej niż w poprzedniej tabeli, tylko jak znam życie, za planami pójdą zaraz realne wartości historyczne.

W takim układzie wydaje mi się sensowne rozszerzenie istniejącej tabeli o kilka dodatkowych kolumn i wierszy, zamiast budowania oddzielnej tabeli o podobnej wielkości z nowymi danymi. O ile z kolumnami nie widzę przeszkód, o tyle z nowymi wierszami już tak.

1. Pytanie szczególne - jak to zrobić, aby to miało ręce i nogi?
2. Pytanie ogólne - są jakieś dobre praktyki przechowywania danych w czasie?

Liczę na podpowiedzi, jak ugryźć problem.

Nowa tabela

ralf napisał(a):

Nowa tabela

Jeśli 2 oddzielne, w tym jedna nowa,
mam wtedy sporo danych zdublowanych, a do tego w zasadzie każdy dostęp do danych z jakiegoś okresu będzie przeszukiwaniem i łączeniem z obu tabel. A wszystko na małym synology :)

Nowa w sensie - jako te dwie połączone?
Trzymać w niej nadmiarowe "puste" wiersze (dla każdej godziny na dobę dla każdego sklepu) na zapas na podobne przypadki w przyszłości?

Jakich zdublowanych? idsklepu idtypudnia to są przecież klucze czyli naturalnie są w wielu miejscach, po to są joiny żeby ich używać. Tworzenie pustych wierszy jest takie sobie. Chyba lepiej generować je w zapytaniu jeżeli będzie potrzebna ciągłość przy zwracaniu danych.

Zdublowanych w tym sensie, że w obu tabelach będą dane które mogłyby być w jednej
Przy obecnym rozwiązaniu, że w danym dniu, dla danej godziny, w danym sklepie mam zagregowane... ilości klientów, obroty marże itp, dołożenie nowych kolumn miałoby sens
Te dane są cały czas wykorzystywane do analizy porównawczej nowych danych. dodatkowe koszty rozłożone w każdej godzinie wydają mi się sensownym rozwiązaniem. Jeden select i całość wyników jest dostępna.
Osobna tabela, to identyczny okres czasowy (więc kolejne 16 mln wierszy) a coś mi mówi, że jak raz złożę w wyniki z kosztami, to już zawsze będzie to wymagane. Nie mówię, że joiny są złe. Tylko czy w tym wypadku nie byłyby bezpotrzebnym obciążeniem?

Chyba źle się zabrałem do wyjaśnienia mojego problemu.
Jest nim to, że dotychczasowa tabela była zbudowana w oparciu o dane sprzedażowe. Dlatego z dziś z jednego sklepu w dajmy na to Rzeszowie właśnie otrzymuję ostatnie wpisy (z godziny od 20 do 20:59) i na tym na dzisiaj koniec. Pracownicy zaś będą tam jeszcze 2 godziny. Uzupełnienie tej tabeli o dane roboczogodzin wymaga dodatkowej kolumny i wierszy z brakujących godzin

muszę więc:
albo - uzupełnić dane z półtora roku o brakujące okresy (bez handlu za to z kosztami pracy),
Dodać kolumnę, i przelecieć przez wszystkie wpisy dodając wartości, a gdy nie ma koniecznego wpisu data/godzina/sklep to zwyczajnie go dodać?

albo - zbudować całość od nowa z pełnymi 24 godzinami dla każdego dnia w każdym sklepie (aby się później nie martwić o inne "nowe" dane rozkładane w tej rozdzielczości czasu

albo - i tu mi się pomysły skończyły. A doświadczenie mi mówi, że koniec moich pomysłów nie oznacza braku lepszych rozwiązań.

Dlatego pytam :)

i nad czym tu się zastanawiać? Dodaj te kolumny, napaś je danymi i tyle.

Cóż,
Widać musiałem to wszystko napisać, aby sobie to jakoś poukładać w głowie.
Pk złożony na data_godzina + id_sklepu i lecę insertami. a gdy mi postgres się zapulta że klucz już istnieje to update.
Powinno działać w przyszłości, o dowolne nowe dane, bez konieczności pilnowania kolejności agregacji.
Może się to codziennie mielić przez pół nocy, ważne aby w dzień dane były gotowe i możliwie szybko dostarczone.
A jak już mały synology nie da rady ... cóż może w końcu znajdzie się jakiś budżet :)

Dziękuję za pomoc