Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [MySQL] Struktura magazynu
Forum PHP.pl > Forum > Przedszkole
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 smile.gif

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

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 smile.gif 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 smile.gif

Pomiędzy magazynem a produktem mamy relację N do N - wiele do wielu - tego nie zmienisz wink.gif
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ć.

Cytat(Sephirus @ 22.12.2011, 14:56:57 ) *
Oczywiście jeśli masz jakieś dziwne/nietypowe rzeczy robić z tymi magazynami (...)


Żadnych udziwnień nie będzie, ja jestem normalny wink.gif.
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 smile.gif

No, ale podstawę już masz, teraz jak chcesz to doprecyzuj smile.gif Np. grupami towarowymi smile.gif
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 smile.gif 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
Cytat
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ć wink.gif - 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.

Cytat
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 wink.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.