Marcin Król napisał(a):

Krzysztof Drewicz napisał(a):

...

posunąć się np do przesuwania usuniętych operacji z cash do cash_deleted i ewentualnie dawać "select * from cash union select * from cash_deleted" albo zrzucić na DB domyślne trzymanie pola "deleted" i

A może po prostu przyjąć strategię na 1.7.x czy 2.x że każda tabelka ma kolumnę deleted i każde zapytanie będzie z where deleted = 0? W zasadzie blobów żadnych nie trzymamy, to nie powinno się nic złego z bazą dziać, a statystyki mogą być wyjątkiem.

Wiesz, mi tam rybka w sumie, ale w users mamy jakby status już. To nam życia nie ułatwi że deleted=1 i status= cokolwiek. Trzebaby się pokusił o moduł robiący międzymordzie również na poziomie perla (i C). Co zaś z nodes ? Po usunięciu i próbie dodania z takim samym IP bądź maciem czy powinien być grzeczny komunikat? Nodes też status mieć może... Zaś co do cash to ta tabelka jest mocno kłopotliwa zwłaszcza że chyba planujemy tam mocne zmiany. Może głoś z końca sali w postaci "księgowane datą/godziną" + timestamp kiedy to faktycznie miejsce miało (jeśli rozksięgowywujesz np wyciąg raz-na-tydzień to ma to głębszysens). I dodać w cash status na początek np rozliczono z automatu, wstępnie rozliczono i zatwierdzono.

Oczywiście jakieś rozwiązanie "po środku" jak zwykle wyjdzie najlepiej: Możliwość robienia "ack" albo "checkpointów" tak że DB nie pozwala księgować nic wstecz przed tą datą. ot, np jest 15 maja a Ty ack robisz 1 kwietnia. Mało zmian w bazie i ma to znamiona sensu (coś a'la zamykanie okresów księgowych).

kd.