Witam

Jestem w trakcie pracy nad budowa systemu dla magazynu.
Bedzie to moja praca dyplomowa i juz na wstepie napotkalem nastepujacy problem i jestem ciekaw jak Wy sobie byscie z nim poradzili...

Dokument moze miec status:
1. Otwarty - mozna nanosic zmiany, usunac, edytowac, dodawac towary
2. Zaksiegowany - nie mozna nanosic zmian, mozna go wydrukowac

Do kazdego dokumentu beda przypisane pozycje towarowe, od jednego do ...powiedzmy 99.
Tylko towary z dokumentow zaksiegowanych beda wliczane do bilansu, inwentaryzacji itd.
I tu nasow sie pytanie jak to rozplanowac w bazie?

Czy trzymac oby dwa rodzaje dokumentow w jednej tabeli, oznaczajac status pole boolinowskim?
Czy stworzyc osobne tabele, jedna dla dokumentow otwartych i druga, w ktorej nie bedzie mozna zmieniac danych (dodawanie i tylko odczyt)? ...ale za to wiecej klopotow przy prezentacji ich w jednym widoku...

Pozdrawiam H.
ps. nie mam polskich znakow

jedno i drugie rozwiązanie ma swoje plusy i minus... ja stworzył bym dwie tabele i bym miał jasność co jest co... to jest moje zdanie, co do tej prezentacji to nie wiem czy to był by kłopot jakaś relacja i powinno się wszystko bez problemu udać.

Potrzebujesz dwie tabele - jedna to "Dokumenty" a druga "Pozycje" Typ, status i inne flagi oznaczasz w dokumencie.
Czy jeśli księgowa oznacza fakturę jako opłacona, to przepisuje ja na osobny druczek, czy przywala pieczątkę?

~piotrooo89: pokaż mi zalety drugiego rozwiązania - jakiekolwiek...

W tabeli "Pozycje" dajesz pole dokument.id aby wiązało dane pozycje (może być ich nieskończenie wiele) do dokumentów.

Narazie nie doszedłem do tematu faktur... na początek chcę się skupic na zarządzaniu towarami i tak naprawdę nie wiem, czy będę projektował funkcjonalność sprzedażową. Czy jedno bez drugiego nie może istnieć?

Wracając do tematu, czyli dobrze będzie tak:

[Towary]

połączone z

[Pozycje na dokumentach]

połączone z

[Dokumenty]

i wątek się rozwija
Przykładowa sytuacja: Dokument zamknięty, zablokowane powiązane rekordy w tabeli łączącej, a użytkownik chce zmienić nazwę towaru... po tej opracji drukuję dokument z tym samym numerem i datą, ale w jednej z pozycji z innym towarem...
Czy blokować również edycję towarów, które znajdują się na dokumentach zamkniętych?
Czy można to rozwiązać w inny sposób?

Dziękuję wszystkim za odpowiedzi (przeszłe i przyszłe)

Faktura to był przykład obrazujący Twoje pytanie
Co do dalszej części, to oczywiście dokument musi być powiązany (jeden-do-wielu) z pozycją, a pozycja - i tu masz dwie drogi:

• Łączy się przez Id z Towarem
• Nie łączy się z towarem, a podczas tworzenia nazwa towary jest kopiowana do pozycji

Osobiście, połączyłbym oba punktu czyli trzymałbym w pozycji zarówno ID towaru jaki ma na niej figurować, jak i nazwę (i cenę i inne kluczowe dane) - nadmiarowość danych to akurat nic strasznego.
W tym momencie, poprzez Id, możesz wyszukać wszystkie sprzedaże tego produktu, oryginał towaru może sobie zmieniać nazwę, a na dokumencie pozostaje nazwa z chwili zakupu.

Dzięki scanner, o to mi chodziło, jak to ugryźć.
Wkleję koncepcję jak będzie dopracowana.

Scanner już zwrócił uwagę na cenę, ale właśnie to najważniejsze.
Może być tak, że cena danego towaru tuż po dodaniu go do pozycji ulegnie zmianie, wtedy mając kopię ceny z chwili dodawania towaru do pozycji mamy cenę jaka była.
To też pozwoli nam sprawdzić sobie po czasie jak się kształtowała cena danego towaru.

Ale tylko wtedy jesli ten towar bedzie kupowany

Można wprowadzić wersjonowanie towaru, tzn. każda zmiana powoduje utworzenie nowej wersji, a wtedy łączymy dokument nie z id towaru, a z id wersji towaru. Wtedy nie dość że mamy wszystkie dane, to jeszcze można stworzyć statystyki zmian danego towaru.

~Sedziwoj: Z doświadczenia wiem, ze to jest nieco uciążliwe w implementacji.

W mentax'owym CRMie stosujemy taką technikę, że każda tabela z typem danych ma swoją kopię z historią zmian - odpowiednio napisana procedura składowana w plpgsql i przeniesienie danych podczas edycji/usuwania dzieje się niejako automagicznie - a dzięki temu nie obciąża się tabeli głównej. Zaś samo dotarie do historii danego rekordu to tylko jedno zapytanie do tabeli historii. Oczywiście to tylko pobieżny opis, ale myślę, ze na razie wystarczy.

@scanner
Zwróć na jedno uwagę, ja nic nie napisałem jak to realizować.
Ale umieszczanie w jednej tabeli aktualnych produktów i ich starszych wersji nie jest za ciekawe, chyba że to trochę inaczej rozwiąże. Ale to już zależy co chce się osiągnąć.
Na pewno dla dobra serwera z bazą, dostęp do aktualnych wersji produktów powinien być tak samo szybki jakby nie było wersjonowania.
Ten sposób co podałeś, jest i prosty i dobry.

P.S. Opis pobierze przy tym poziomie abstrakcji są dobre, jak już się coś wybierze, to wtedy wejście w konkretny sposób realizacji jest przydatny, teraz by tylko utrudniał.

Czy to o to chodziło?