Przechowywanie histori w bazie danych

0

Witam,

Mam dane finansowe, ktore musze przechowywac wszsytkie zmiany hostoryczne. Czyli np produkt skarpeta A ma cene w styczniu 10zl, a w lutym 14zl. Mam jedna tabele parent i 3-4 child. Jakis pomysl jak skutecznie moge przechowywac te zmiany. Zeby wiedziec jaka cena byla na zamowieniu zrealizowanego w styczniu a jaka w lutym. Zapisuje takie dane w tableach zamowienia, ale tutaj musze miec historie. Nie moge tego obejsc.

Myslalem, nad utworzeniem tabel z historia i triggery. Tylko, ze to tez lipa, bo przeciez ID bedzie to samo to jak polacze tabele ze soba? Bo dacie?

1

W hurtowniach danych jest to zagadnienie znane jako SCD
https://en.wikipedia.org/wiki/Slowly_changing_dimension
Moim zdaniem najprościej wpisywać aktualną cenę w zamówieniu, a historię przechowywać w innej tabelce, ale raczej do analityki a niekoniecznie łączyć ją z zamówieniami.

2

Towary zazwyczaj na stan przyjmuje się fakturą - czyli, dostajesz towar i fakturę do niego. Na tej podstawie tworzysz u siebie dokument PZ (przyjęcie zewnętrzne) i wciągasz te produkty na stan z taką i taką ceną.

Sprawdzenie potem ceny jaką miał produkt np. w styczniu to nie problem, bo patrzysz jakim dokumentem je wciągnąłeś i tam masz - skarpety 10zł netto.

IMHO to taka podstawa w działaniu każdego oprogramowania magazynowego.

1

Trzymaj cene, rabaty i podatki przy zamowieniu. Zgadywanie ceny po fakcie (po sprzedazy) na podstawie danych historycznych moze byc awykonalne jesli wezmiesz pod uwage aktywne promocje, zastosowane rabaty, roznorodnosc cen w zaleznosci od paczki magazynowej, zmieniajace sie warunki podatkowe.

0

W większości systemów ecommerce masz zamówienia przechowywane jako osobne byty. Przechowuje się nie tylko cenę, ale też np. nazwę produktu, stawkę vat, wysokość naliczonego podatku i ogólnie wszystko. Robi się tak dlatego, że musisz wiedzieć co dokładnie klientowi sprzedałeś - produkty w czasie przecież się zmieniają (np. pod tym samym sku produtk nazywa się inacze), zmieniła się stawka vat produktu etc.

Co do przechowywania samych zmian cen w oderwaniu od zamówień to po opisie problemu przychodzi mi event sourcing - wbrew obiegowej opinii nie musisz go użyć w całym systemie, a możesz właśnie wyłapać kilka takich obszarów, gdzie ma to sens i w Twoim przypadku przechowywanie eventów zmiany ceny zamiast samej ceny by miało sens.

0
poniatowski napisał(a):

Myslalem, nad utworzeniem tabel z historia i triggery. Tylko, ze to tez lipa, bo przeciez ID bedzie to samo to jak polacze tabele ze soba? Bo dacie?

To jest sluszna idea zeby zrobic trigery ma tabele i wrzucac do histroycznych i ID powinno byc takie samo ze starej tabeli. co to znaczy "jak polacze tabele ze soba" po co chesz cos laczyc? przeciez podajesz tylko produkt id (skarpeta . id=3245) i widzisz z istorycznej jak zmianiala sie cena, przez kogo i kiedy. to co ty chcesz laczyc?

1
chomikowski napisał(a):
poniatowski napisał(a):

Myslalem, nad utworzeniem tabel z historia i triggery. Tylko, ze to tez lipa, bo przeciez ID bedzie to samo to jak polacze tabele ze soba? Bo dacie?

To jest sluszna idea zeby zrobic trigery ma tabele i wrzucac do histroycznych i ID powinno byc takie samo ze starej tabeli. co to znaczy "jak polacze tabele ze soba" po co chesz cos laczyc? przeciez podajesz tylko produkt id (skarpeta . id=3245) i widzisz z istorycznej jak zmianiala sie cena, przez kogo i kiedy. to co ty chcesz laczyc?

Panie jakie niggery triggery... Wystarczy zaprojektować system magazynowo-sprzedażowy aby obsługiwał standardowy flow dokumentów i problem znika.

0

Triggery zwane inaczej "ostatecznym rozwiązaniem DBA-ja"?
Jak modyfikacja aplikacji jest nieopłacalna to się dorzuca triggery, widoki zastępują tabele, dorzuca się gdzieniegdzie indeksy.
Baza potem wygląda dziwnie, czasem zwalnia, ale nie trzeba tykać apki/apek.

0

@vpiotr: no to takie łatanie baku z paliwem... Pomaga na jakiś czas. Tylko potem robi się jedną wielka kula gów...a, której nikt nie chce ruszać, bo wszystko może się zdarzyć...

0

@poniatowski: moim zdaniem również uruchamianie triggerów do budowania danych historycznych to trochę na wyrost. Przecież wystarczy jedna tabela "orders" gdzie będziesz przechowywał dane jakie były aktualne w momencie zamówienia (poza ceną, VAT'em ilością itd to jeszcze dane odbiorcy, przesyłki itp). I tak musisz takie coś wygenerować chociażby, żeby pokazać klientowi historię jego zamówień. Kolejna sprawa, to ID produktu. Nie trzymaj ID produktu. Za dwa lata może się okazać, że tego ID wcale nie ma. Co najwyżej trzymaj tam nazwę produktu i jego (przykładowo) SKU.

0

@leonpro778: Id produktu nie moze sie zmienic czy nie byc. jezeli produkt jest kasowany to albo przez softDelete czyli jest dodana data skasowania ale wpis caly czas istnieje albo przez status np: unavilable czy inny ktory nie pokazuje produktu we sklepie. Historia w Orders to co innego niz historyczna tabela. Moze byc tak ze od lutego do marca nikt nie kupi produktu. a w miedzy czasie okaze sie ze ktos z pracownikow zmienil cene na skarpete zamiast 20 zl to 2000 zmienil 4 lutego potem np 11 lutego zmienil na 3 tys zlotych a na koniec miedsiaca na 20 zl. i bys nie wiedziasl nawet kto to zmienil, kiedy, na jaka cene bo by nie bylo zamowienia. A tu chodzi o to by miec wglad wlasnie w takie zmiany.

0

@chomikowski: No to wystarczy tabela przechowująca zmiany w edycji produktów i przy każdorazowej edycji produktu dodajemy taki zapis. Również bez triggerów się obejdzie :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1