Witam wszystkich. Stworzyłem tabele produkty oraz tabele zamowienia (id_zamowienia, id_produktu, id_klienta) - tabela ta zawiera numery id produktów kupionych przez danego klienta. W tabeli produkty są zapisane nazwy produktów oraz ich ceny. Jeżeli ceny dla produktu x mogą zostać zmienione 40 razy w ciagu jednego roku, niektóre produkty mogą zostać w ogóle usunięte ze sklepu to jak wtedy wyświetlić historię zamówień jakie zrobił klient X? Czy za każdym razem gdy np. cena produktu X zostaje zmieniona zostawić starą wersję rekordu z odpowiednią datą? Gdzieś muszę trzymać, że klient X kupił rok temu buty za 200zł a teraz te same są za 250zł. Przenosić rekordy do tabeli np. archiwum_zakupów? czy trzymać 40 wersji produktu X zmienionych przez pewien okres czasu i powrownywać z datą zakupu? Pozdrawiam

Ja bym po prostu dodał do tabeli zamówienia kolumnę cena i kolumnę w produktach, która informowałaby czy produkt jest usunięty.

A co z nazwą produktu? Zmieni się np. nazwa produktu X na Y, zmienią się zdjęcią, cena itd to wyjdzie w histori, że klient który kiedyś kupił produkt X za 150zł teraz widzi że kupił produkt Y ale cena została ta sama

W systemach księgowych w historii przechowuje się pełne dane o zamówieniach, czyli nazwy produktów, ceny, stawki vat (one też się zmieniają w czasie), dane adresowe/fakturowe itp itd. Jednym słowem chodzi o to abyś fakturę/zamówienie mógł zawsze wydrukować w takiej formie w jakiej złożył je klient - nawet po 5 latach.

BTW. Cena to już w ogóle minimum - co zrobisz jak klient złoży zamówienie po cenie x, zmienisz cenę, a potem zrealizujesz zamówienie po cenie bieżącej, zamiast tej z zamówienia?

Przy kazdej zmianie produktu wersja przed zmiana powinno trafiac do archiwum. Wowczas nie stracisz info o zmianach produktu.
Archiwum to moze byc oddzielna tabela, lub ta sama tabela tylko z dodatkowym pole ARCHIWUM lub cos w ten desen. Osobiscie sklaniam sie ku oddzielnej tabeli dzieki czemu przy wyszukiwaniu aktualnych produktow baza nie bedzie musiala poruszac sie po starych danych.
Dodatkowo musisz miec jakis identyfikator, ktory bedzie laczyl wszystkie wersje produktu i bedzie wiadomo ze dotyczy to akurat danego produktu.

Faktycznie stworzę tabelę archiwum gdzie będę trzymał różne wersje produktu np. o id 5 ale każda z inną datą. Po dacie złożenia zamówienia będę wiedział o który dokładnie produkt chodzi..

Odgrzeję tutaj temat dalej,
otóż mam problem implementacyjny z łączeniem tabeli produky z wieloma tabelami, które opisują cechy danego produktu. Np. tabele: vat, dostawy, rabaty, cechy, waluty itd itd.. składają się na ogólną budowę produktu. Jakim sposobem wiązać ze sobą wszystkie tabele. Pewne wiersze z tabel w.w mogą się zmieniać, np. cechy, waluty mogą zostać usuwane, modyfikowane. W związku z tym, żeby użytkownik mógł wyświetlić sobie podsumowanie swojego zamówienia, które złożył miesiąc musiałby mieć aktualny stan produktu na daną chwilę. Aby opierać się na łączeniu tabel gdzie wyznacznikiem łączenia jest data aktualizacji tabeli musiałbym zmieniać datę aktualizacji dla wszystkich tabel. Mając 100 tabel opisujących produkt - aktualizacja, którejś z tabeli składowej produktu wiązała by się z aktualizacją daty pozostałych 99 tabel. Jest jakieś lepsze, mądrzejsze, bardziej efektywne rozwiązanie tego problemu? Pozdrawiam wszystkich.