Witam

Jestem na etapie projektowania struktury bazy danych dla systemu zarządzania stanami magazynowymi. Z założenia projekt nie ma być skomplikowany.

Napotkałem na problem podczas określania sposobu przechowywania informacji o stanie magazynowym konkretnego przedmiotu oraz historii zmian tych stanów wynikających z odpowiednich dokumentów.

Jako założenia przyjąłem, iż:

• pojedynczy rekord w tabeli PRZEDMIOTY jednoznacznie identyfikuje daną pozycję materiałową,
• zmiany typu przychód/rozchód wynikają z odpowiednich dokumentów, o których informacja przechowywana jest w tabeli DOKUMENTY,
• w związku z powyższym założeniem w tabeli ZMIANY oprócz dwóch kluczy obcych do tabel PRZEDMIOTY i DOKUMENTY (będących jednocześnie kluczem głównym – kombinacja dwóch kluczy obcych) utworzyłem pola ‘przychod’ i ‘rozchod’ (w sytuacji gdy nie określono wartości danego pola, domyślna wartość wynosi 0).

W sytuacji, gdybym chciał uzyskać stan magazynowy konkretnego przedmiotu, za każdym razem musiałbym przebrnąć przez poniższe kroki:

1. Z tabeli ZMIANY wybrać rekordy opisujące zmiany ilościowe dotyczące konkretnego przedmiotu posiłkując się kluczem obcym przedmiot_id.
2. Zsumować wartości przechowywane w kolumnach ‘przychod’ i ‘rozchod’ dla otrzymanych rekordów.
3. Od sumy wartości obliczonej dla kolumny ‘przychod’ odjąć sumę wartości obliczonej dla kolumny ‘rozchod’ uzyskując tym samym stan magazynowy konkretnego przedmiotu.

Zastanawiam się, czy lepszym rozwiązaniem nie byłoby dodanie do tabeli PRZEDMIOTY pola ‘stan’, w którym przechowywałbym aktualną ilość danego indeksu materiałowego i uaktualniał tę wartość podczas dodawania nowego rekordu do tabeli ZMIANY (utworzenie historii zmian) o zmienioną wartość. Podczas uzyskiwania aktualnego stanu magazynowego danej pozycji nie musiałbym za każdym razem go obliczać tylko ograniczyłbym się do pobrania wartości z pola 'stan'. Czy takie rozwiązanie byłoby wydajniejsze i zgodne z zasadami projektowania relacyjnych baz danych?

Do wiadomości dołączam diagram bazy danych. Mniej istotne tabele dla rozwiązania tego problemu ukryłem dla poprawy czytelności diagramu.



Przy okazji chciałem uzyskać informację odnośnie tworzenia klucza podstawowego na podstawie kluczy obcych. Na diagramie widnieje rozwinięta tabela PRZEDMIOT_KATEGORIA, która zawiera rekordy określające przydział konkretnego przedmiotu do odpowiednich kategorii wynikający z określonego dokumentu. Czy w tej sytuacji klucz podstawowy powinien zostać zdefiniowany jako trzy klucze obce, czy też w zupełności wystarczą dwa? Zastanawiam się w jaki sposób wpływa to na szybkość wykonywania zapytań związanych z tą tabelą. Poniżej kod SQL do utworzenia tabeli PRZEDMIOT_KATEGORIA:

[SQL] pobierz, plaintext 
CREATE TABLE przedmiot_kategoria (
	przedmiot_id SMALLINT UNSIGNED NOT NULL,
	kategoria_id TINYINT UNSIGNED NOT NULL,
	dokument_id SMALLINT UNSIGNED NOT NULL,
	PRIMARY KEY (przedmiot_id, kategoria_id, dokument_id),
	INDEX (przedmiot_id),
	INDEX (kategoria_id),
	INDEX (dokument_id),
	FOREIGN KEY (przedmiot_id) REFERENCES przedmioty (przedmiot_id) ON DELETE NO ACTION ON UPDATE NO ACTION,
	FOREIGN KEY (kategoria_id) REFERENCES kategorie (kategoria_id) ON DELETE NO ACTION ON UPDATE NO ACTION,
	FOREIGN KEY (dokument_id) REFERENCES dokumenty (dokument_id) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=INNODB;
[SQL] pobierz, plaintext 

Z góry dziękuję za pomoc,
PA

A co Ci szkodzi mieć oba te sposoby? Pole 'stan' uwolni Cię od ciągłego joinowania i sumowania. Tym samym zyskujesz na wydajności.