[MySQL] Struktura magazynu Opcje

[m_w]

Witam,

jestem na etapie projektowania struktury tabel dla magazynu. Stworzyłem sobie takie tabele:

Kod

Produkty:
- id
- nazwa

Kod

Magazyny:
- id,
- nazwa,
- opis

Kod

MagazynyStany:
- id_magazynu
- id_produktu
- ilość

Struktura wydaje się w porządku, ale nie do końca mnie satysfakcjonuje. Przede wszystkim zastanawiam się nad przechowywaniem stanów magazynowych. Czy pole id_produktu powinno być unikalne? Jak według was powinna wyglądać struktura magazynu?

Pozdrawiam,
m_w

[Sephirus]

Ja powiem tak. Jako absolutna podstawa to jest OK.

Liczy się prostota i wydajność. Jeżeli chodzi normalizację to też nie ma nic do zarzucenia

Czemu zakładasz że taka prosta struktura może Cię w pełni nie satysfakcjonować?

Oczywiście jeśli masz jakieś dziwne/nietypowe rzeczy robić z tymi magazynami to opisz dokładnie co tam jeszcze chcesz móc robić. A jeśli nie to taka struktura Ci starczy Plus jakieś dodatkowe pola jeśli są potrzebne.

Pole id_produktu NIE MOŻE być unikalne - bo tak jak w życiu - w wielu magazynach może być wiele takich samych produktów

Pomiędzy magazynem a produktem mamy relację N do N - wiele do wielu - tego nie zmienisz

Ten post edytował Sephirus 22.12.2011, 14:58:30

[m_w]

Zastanawiam się głównie nad strukturą tabeli MagazynyStany. Załóżmy że mam jakiś produkt na stanie. Czy przy przyjęciu do magazynu nowej prartii, aktualizujemy ilość produktów na stanie, czy dodajemy nowy rekord z ilością produktów (wydaje mi się że pierwsze rozwiązanie jest lepsze).

Kolejną rzeczą którą będę potrzebował to przychody i rozchody wewnętrzne (dla konkretnego działu) oraz przyjęcia i wydania zewnętrzne. Mam pewne rozwiązania na myśli, ale chciałbym poznać wasze zdanie na ten temat, aby za bardzo nie namieszać.

Oczywiście jeśli masz jakieś dziwne/nietypowe rzeczy robić z tymi magazynami (...)

Żadnych udziwnień nie będzie, ja jestem normalny .

[krystianroza]

Zależy też od branży, bo możesz w spożywczaku dać dodatkowe informacje jak bardzo ważna data ważności, a np. dla sprzętu RTV inne parametry

No, ale podstawę już masz, teraz jak chcesz to doprecyzuj Np. grupami towarowymi

[thek]

@m_w: rozpatrz coś takiego jak Dział_magazynu. To pozwoli Ci pokombinować z Obrotem_wewnętrznym, który nie będzie dotykał stanu ogólnego, ale będziesz mógł rozdysponować tę ilość pomiędzy działy. W razie wydania zewnętrznego, zobaczysz który dział ma ile czego i wydasz. Innymi słowy klient poprosi o 100 sztuk X i dostaje, ale to Magazyn wie, że X1 musi pobrać z DziałuA oraz 100-X1 z DziałuB W ten sposób ukrywasz tak naprawdę pewną implementację wewnętrzną, czyli idziesz tym torem, który jest dla obiektowości idealny -> enkapsulacja. Magazyn dysponuje metodami pobierania z działów i wysyłania do działu lub ewentualnie przesyłki między działami (to tak naprawde pobierz i wyślij w jednym).

To o czym wspomniał krystianroza wiązało by się z większym doprecyzowaniem. Nie miałbyś już w magazynie/dziale hedynie id_produktu i jego ilości, ale pojawiła by się Partia produktu, czyli mocniejsze rozwarstwienie i produkt na stanie magazynu/działu koniecznie musiałby być sumowany by poznać całkowitą ilość na stanie. A że takie operacje byłyby konieczne do zapamiętania, to rośnie nam ilość klas obsługujących.
Takie wydanie wewnętrzne to przesunięcie produktu z partii R w ilości X z działu A do działu B. Konieczna klasa obsługi wewetrznej typu pobierz_z_działu(A, partia, ilość), wyślij_do_działu(B, partia, ilość). Zauważ, że jeśli mamy kilka sztuk z każdej partii to przesunięcie większej ilości do magazynu B ze wskazaniem po prostu "przyslij do B truskawki", bez precyzowania z jakiej dostawy, angażuje operację przesyłu kilkukrotnie tak, by zgadzała się ilośc sumaryczna do przesłania, bo nie definiuje czy ma to być jedna partia produktu czy można mieszać.

Jeszcze gorzej w przypadku zewnętrznej, ktore też ma swoją klasę zawiadującą stanem całości magazynu... korzystając wewnątrz więdzy innymi z klasy przesyłu wewnętrznego, bo musisz użyć pobierz_z_działu(), ale byłaby to wewętrzne użycie metody na rzecz wydaj_z_magazynu.

Zauważ, że jednak CAŁY proces to tak naprawdę tylko kontrola nad malutkimi procesikami klas działu i magazynu. Można jedynie próbować to tak zorganizować, by partie się nie "fragmentowały", a więc jeśli widzimy partię porozrzucaną po kilku działach, co jakis czas zebrać ją do kupy w jednym dziale.

[Sephirus]

Zastanawiam się głównie nad strukturą tabeli MagazynyStany. Załóżmy że mam jakiś produkt na stanie. Czy przy przyjęciu do magazynu nowej prartii, aktualizujemy ilość produktów na stanie, czy dodajemy nowy rekord z ilością produktów (wydaje mi się że pierwsze rozwiązanie jest lepsze).

Wg mnie najlepiej by było aby to był "UPDATE" na MagazynyStany ale także odpowiedni insert do tabeli powiedzmy "MagazynyDostawy" - gdzie mógłbyś do historii po prostu dopisać kiedy, ile, jakiego produktu, było dodane do jakiego magazynu - moze się przydać - podobnie z samym wydawaniem (na zasadach ogólnych) też powinna być jakaś historia tego - można to ująć w jednej tabelce z dodatkowym polem mówiącym czy te przedmioty przyszły czy poszły.

Kolejną rzeczą którą będę potrzebował to przychody i rozchody wewnętrzne (dla konkretnego działu) oraz przyjęcia i wydania zewnętrzne. Mam pewne rozwiązania na myśli, ale chciałbym poznać wasze zdanie na ten temat, aby za bardzo nie namieszać.

No tutaj powinno Ci wystarczyć to co napisałem + post @Thek'a