Witam,
zastanawiałem się ostatnio nad pewnym problemem, a mianowicie jak zapisywać dane w tabeli z zapamiętywaniem stanów poprzednich.
Prosty przykład
mam tabelę kontrahenci z kolumnami idKontrahenta, nazwa, adres
oraz drugą tabelę faktury z kolumnami idFaktury, idKontrahenta, data, ....

i teraz dodaję kontrahenta i wystawiam mu faktury.
Po jakimś czasie kontrahent zmienił adres, czyli robię update na tabelę kontrahenci.
Ale niestety powstaje problem, zostaną zmienione dane w już wystawionych fakturach co jest niewłaściwe.

Rozwiązanie jakie wymyśliłem:
do tabeli z kontrahentami dodaje dwie dodatkowe kolumny: dataOd oraz dataDo które zrazem z idKontrahenta są kluczem głównym.
Robiąc UPDATE de facto tworzę kolejny rekord zmieniając odpowiednio daty
Czyli np.
po dodaniu kontrahenta mam jeden rekord:
idKontrahenta,dataOd,dataDo, nazwa, adres
1 , 01.01.2012, 00.00.0000, 'nazwa 1', 'adres 1'

natomiast po UPDATE mam dwa rekordy
1 , 01.01.2012, 02.02.2012, 'nazwa 1', 'adres 1' <-- rekord historyczny
1 , 02.02.2012, 00.00.0000, 'nazwa 1', 'adres 2' <-- aktualny rekord

Robiąc SELECT z tabeli faktury(złączenie z kontrahentami) muszę dodatkowo uwzględnić przedział czasowy.
Do robienia INSERT'a i UPDATE oczywiście muszę napisać odpowiednie procedury.
takie rozwiązanie ma pewną poważna wadę,a mianowicie nie mogę użyć auto inkrementacji :/


Czy takie rozwiązanie jest dobre/sensowne ? są jakieś lepsze co o tym myślicie

Wystawiona faktura jest "święta" - nie można nic w niej zmieniać. Zazwyczaj robi się to w ten sposób, że kopiuje się odpowiednie pola z tabeli kontrahenci do tabeli nagłówka faktury. I to dobry zwyczaj.
Sposób, który pokazałeś to może być dobry, ale do historii zmian danych. (Sam też taki używam). Niestety może być niewydajny.

Zdubluj przy każdej fakturze wszystkie dane kontrahenta jak i sprzedawcy - każde pole.
Wszystko na fakturze można zmieniać (zwłaszcza przed wysłaniem do klienta) i musisz taką możliwość dać.

Oprócz tego chcesz jeszcze przetrzymywać stany poprzednie faktury (wszelkie edycje)?

ok, małe wyjaśnienie.
Przykład z kontrahentami i fakturami był dosłownie przykładem mającym na celu zobrazowanie tego typu problemu.
Innym przykładem mogą być zamówienia w sklepie. Ktoś kupuje produkt, a po jakimś czasie zmieniamy jego cenę ale w zamówieniu musi być cena historyczna. W tym przykładzie powstaje jeszcze jeden problem wszak oprócz historycznej ceny mogą być przydatne takie informację jak stawka vat, czy towar był w promocji, jak była nazwa ....
I co takiej sytuacji

Z jednej strony mogę zrobić tak jak napisaliście, czyli zapisać te dane w tabeli z zamówionymi towarami ale w taki sposób powstają dane nadmiarowe przy każdym zamówieniu.

Drugie rozwiązanie to to o którym pisałem, czyli zapisanie przedziałów czasowych przy edycji ale tutaj również mogą powstawać dane nadmiarowe jeśli np. nie potrzebujemy historycznych opisów które mogą być bardzo długie i zajmować sporo miejsca.

Więc może jakieś inne rozwiązanie?? np osobna tabela na dane historyczne

Co o tym myślicie ?



Z tego co wiadomo to może być dowolnie modyfikowana(w przeciwieństwie do paragonu fiskalnego) do czasu zaksięgowania w tych różnych dziwnych księgach przychodu i rozchodu - czy coś takiego




no właśnie nie wiem jest sens to robić a może ktoś ma doświadczenie z programami księgowymi i podzieli się jak to wygląda w tego typu programach

Miałam do czynienia z kilkoma tego typu systemami i w każdym rozwiązane było to dokładnie w ten sposób:



Danych nadmiarowych nie unikniesz w tej sytuacji. Poza tym, po jakiejkolwiek zmianie nie są już one nadmiarowe. Jeżeli nie wykorzystujesz w żaden inny sposób tej historii zmian, nie ma sie co w to bawic. To samo tyczy sie np. zmian adresow klienta - w tabeli z zamowieniami/fakturami zapisujesz po prostu kopie adresu, aktualnej ceny itp. Prawdopodobnie nie uciekniesz od takiego rozwiazania.