Produkt - właściwość - ilość właściwości - podział na tabele czy jeden string?

Odpowiedz Nowy wątek
2018-04-16 10:35
Mistrzowski Szczur
0

Dzień dobry, mam pytanie odnośnie w jaki sposób mogę podzielić produkt na właściwości i zarządzać ilościami tej właściwości.

Przykład:
Mamy produkt, który jest dostępny w dwóch kolorach (czerwony:2 i niebieski:4) (2 i 4 to ilości danego koloru) gdy ktoś zamówi produkt o danym kolorze system z automatu odejmie zakupioną ilość produktu od ogólnej ilości przedmiotu oraz od ilości danego koloru.

Pytanie:
Czy odpowiednim będzie utworzenie tabeli properties z polami id oraz property, gdzie w property będzie string "Niebieski:4, Czerwony:2". W tabeli products będzie występować relacja do tabeli properties (produkt będzie zawierał odpowiednie właściwości).

Podczas zakupu system będzie wyciągał z tabeli cały string (Niebieski:4,Czerwony:2) patrząc na to jaki produkt jest aktualnie podczas transakcji explodował ten stroing po ",", następnie po ":", oraz odpowiednio sprawdzał, validował, updatował ten wiersz w tabeli z już pomniejszoną wartością ?

Mam już skonstruowany cały skrypt do tego, jednakże chciałem zapytać się czy takie coś jest poprawne czy istnieje lepsza metoda?
Jak to jest z awaryjnością tej metody? oraz w jaki sposób wykonuje się takie coś w sposób już bardziej zaawansowany?

Z góry dziękuję za odpowiedzi.

Pozostało 580 znaków

2018-04-16 11:06
0
Mistrzowski Szczur napisał(a):

Czy odpowiednim będzie utworzenie tabeli properties z polami id oraz property, gdzie w property będzie string "Niebieski:4, Czerwony:2".
Podczas zakupu system będzie wyciągał z tabeli cały string (Niebieski:4,Czerwony:2) patrząc na to jaki produkt jest aktualnie podczas transakcji explodował ten stroing po ",", następnie po ":", oraz odpowiednio sprawdzał, validował, updatował ten wiersz w tabeli z już pomniejszoną wartością ?

Niezbyt dobry ten pomysł. Nie lepiej sobie "osłownikować" to wszystko? A jak będziesz chciał zmienić sobie kolory z nazw polskich na angielskie? To jak będziesz to robił?

edytowany 1x, ostatnio: leonpro778, 2018-04-16 11:07

Pozostało 580 znaków

2018-04-16 11:21
0

W tabeli products będzie występować relacja (...)

Związek. Relacja jest synonimem dla słowa tabela (patrz: https://pl.wikipedia.org/wiki/Model_relacyjny).

Jak to jest z awaryjnością tej metody?

Jest wysoce awayjna.

Wyobraź sobie, że dwoje użytkowników zamawia produkt w tym samym czasie - może wystąpić race condition, w wyniku którego Twój skrypt odejmie ilość sztuk tylko od jednego użytkownika, a nie od obydwu (jeden request nadpisze dane po drugim).


Dlaczego nie zrobisz po prostu osobnej tabeli w stylu product_stock, gdzie będą pola product_id, attribute_id, quantity?


edytowany 1x, ostatnio: Patryk27, 2018-04-16 11:21

Pozostało 580 znaków

2018-04-16 11:50
Mistrzowski Szczur
0
Patryk27 napisał(a):

W tabeli products będzie występować relacja (...)

Związek. Relacja jest synonimem dla słowa tabela (patrz: https://pl.wikipedia.org/wiki/Model_relacyjny).

Jak to jest z awaryjnością tej metody?

Jest wysoce awayjna.

Wyobraź sobie, że dwoje użytkowników zamawia produkt w tym samym czasie - może wystąpić race condition, w wyniku którego Twój skrypt odejmie ilość sztuk tylko od jednego użytkownika, a nie od obydwu (jeden request nadpisze dane po drugim).


Dlaczego nie zrobisz po prostu osobnej tabeli w stylu product_stock, gdzie będą pola product_id, attribute_id, quantity?

Tak właśnie zrobię. Dziękuję :)

Pozostało 580 znaków

2018-04-16 14:45
3

Żadne ilości zapisane jako liczba, każda sztuka produktu to powinien być osoby rekord w bazie danych. Jeżeli masz 2 szt. produktu w kolorze A, i 3 w kolorze B, to powinno być 5 rekordów w bazie danych (tabela SQL magazynu). Dobrze radzę - to w dłuższej perspektywie najlepszy sposób na zarządzanie sprawami związanymi z magazynem, analizami finansowymi, nadawaniem indywidualnie cen poszczególnym sztukom produktu, etc. Na początku może się to wydawać uciążliwe, ale później będziesz mi dziękował ;)


edytowany 8x, ostatnio: TomRZ, 2018-04-16 14:50
Niekoniecznie pięć + trzymanie zgrupowanych danych jak najbardziej też ma sens (ze względów wydajnościowych). Chociaż oczywiście masz rację - tabela ze stanami produktów to idealny kandydat na event sourcing :-) - Patryk27 2018-04-16 15:18
Masz rację, tylko trzeba przeanalizować zyski i straty, ten niewielki zysk wydajnościowy może się nie opłacać w porównaniu z problemami jakie wnosi. Wszystko zależy, jeżeli OP pisze coś bardzo prostego, to po co się bawić w rozdzielanie na sztuki, ale przy pełnym systemie "magazynowo-sprzedażowym", z mojego doświadczenia lepiej zrobić tak jak napisałem. - TomRZ 2018-04-16 15:41
I jeszcze inna sprawa: ja tak naprawdę piszę o stanach magazynowych, a nie kopiowaniu cech dla każdej sztuki. Produkt o kolorze A i kolorzez B to powinny być osobne produkty o osobnych identyfikatorach, nawet jeżeli mają ten sam kod EAN. Cechy powinny wynikać z idywidualności/ID produktów. - TomRZ 2018-04-16 15:42

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0