Przechowywanie informacji o produktach

Czesc.

Pisze sobie sklep internetowy i poszukuje optymalnego rozwiazania mojego problemu. Przy dodawaniu nowego produktu okreslam ile sztuk go posiadam. Nastepnie na stronie chce pokazywac informacje ile sztuk zostalo. Zastanawiam sie jak to zrobic.

Lepiej w tabeli, w ktorej mam produkt po kazdym zakupie zmnieszac ilosc produktow (lub zapisywac do innej kolumny ilosc zakupow) czy przy generowaniu karty produktu dodac nowe zapytanie i sprawadzac ile razy zostal zakupiony.

Zawsze bede zapisywal w innej tabeli kto kupil dany produkt, tylko zastanawiam sie czy po zakupie zrobic triggera i umieszczac taka informacje w tabeli z produktem czy pobierac dane z osobnej tabeli ile razy produkt zostal zakupiony i potem obliczac?

Wiem, ze przy malym ruchu wszystko jedno, ale jako ze sie ucze to chcialbym dowiedziec sie, ktore jest rozwiazanie jest lepsze. Byc moze jest jeszcze inne lepsze, dlatego prosze o pomoc.

Oczywiście, że bardziej optymalnie będzie trzymać aktualną ilość w tabeli. I zmniejszać ją po każdym zakupie. Zakupy nie są tak częste, jak generowanie strony. Poza tym, czemu nie skorzystasz z gotowego silnika do sklepów?

Hej,

dzieki za odpowiedz. Lepiej bedzie to zrobic TRIGGER'em czy po prostu INSERT'em?

PS. Spodziewalem sie, ze padnie pytanie dlaczego nie skorzystam z gotowego rozwiazania :-) Bo sie ucze i piszac cos od podstaw wiecej sie naucze :-)

Wiem, ze przy malym ruchu wszystko jedno, ale jako ze sie ucze to chcialbym dowiedziec sie, ktore jest rozwiazanie jest lepsze. Byc moze jest jeszcze inne lepsze, dlatego prosze o pomoc.

bardzo dobrze, ze to napisales. Wiec zacznijmy od tego, ze rozwiazanie nie musi byc "optymalne" (w sensie najszybsze). Najwazniejsze jest zeby kod byl latwy do utrzymywania.

Najlepiej w takim przypadku (to jest wszystko moje subiektywne zdanie) zrobic cos takiego.

1. Uzytkownik wchodzi na sklep. Powiedzmy, ze widzi produkty i ilosci jakie sa dostepne. Jezeli chodzi o to co sie dzieje "za kurtyna" to bym zrobil prostego selecta i pobral informacje o produktach ktore maja byc widoczne (bo i tak musisz je pobrac by je wyswietlic). Cenie oraz ile jeszcze jest go na magazynie. Tak wiec mialbym kolumne ilosc w produkcie.
2. Uzytkownik powybieral kilka produktow. Nie robilbym zadnego zapytania czy update na bazie gdy uzytkownik naciska plusik. Zapisywalbym wszystko "lokalnie" (po stronie serwera, ale nie w bazie). Wiedzialbym jaki produkt chce dany uzytkownik kupic i jego ilosci. Zakladamy (co moze nie byc do konca sluszne), ze ilosc az tak bardzo sie nie zmieni i produkt bedzie dostepny. Mozna powiedziec ze robienie zakupow jest troche operacja "niepewna"
3. Uzytkownik przechodzi do zaplaty. W tym momencie sprawdzilbym czy to co wybral (ilosc produktow oraz cena) nie zmienila sie od tego co wybral. Jezeli sie zmienila poinformowalbym o tym uzytkownika. Jezeli sie nie zmienila to nic bym nie robil
4. Uzytkownik klika zaplac za produkty. Jeszcze raz sprawdzilbym czy wszystko jest na stanie (bo w miedzy czasie ktos moze cos kupil i juz nie ma odpowiedniej ilosci?)
5. Gdy uzytkownik zaplaci to wtedy zrobilbym update na tabeli z dana iloscia danych.

W calej operacji kupna szly by jakies 4 zapytania z czego dwa sa sprawdzajace by uzytkownik nie kupil produktu ktorego nie ma na magazynie. Do tego jeden Update

Dzieki temu nie ma logiki w bazie

@fasadin thx. To co napisales wydaje sie bardzo proste i logiczne, ale dlaczego napisales (posrednio :-)), ze nie jest to najszybsze rozwiazanie? Jak by wygladalo najszybsze?

Czy to rozwiazanie bedzie bezpieczne? Chodzi mi o to czy nie dojdzie do sytuacji, ze dwoch uzytkownikow kupi ostatni produkt. Oczywiscie uwzgledniam sytuacje, ze na stronie bedzie napisane, ze jest jeszcze jeden dostepny, a tak naprawde przed chwila zostal zakupiony, obawiam sie, ze zostanie zaaceptowana jedna transakcja za duzo. Zapisuje dane w dwoch tabelach i w miedzyczasie moze dojsc do zakupu (mam nadzieje, ze domyslasz sie co mam na mysli :p) jak sie przed taka sytuacja zabezpiczyc?

nie napisalem, ze to nie jest najszbysze rozwiazanie. Napisalem, ze szybkosc w tym wypadku nie ma znaczenia.

A szybkosc w tym calym procesie zalezy od tego co bierze najdluzej czasu (tak zwany bottleneck). Moze byc to pobieranie danych. Moze byc to budowanie strony. Moze to byc jakas dodatkowa libka... wszystko zalezy. Dlatego nie ma sensu sie tym przejmowac.

Nie powinno byc takiej mozliwosci ze dwoch uzytkownikow kupi ostatni produkt. Dlatego masz sprawdzenie gdy osoba placi za produkt (dlatego dodatkowe zapytanie). Jezeli sie nie uda produktu kupic (bo bedzie wartosc 0) to wtedy zwracasz blad. Pamiejaj o deadlockach na bazie! (jezeli nie wiesz co to poczytaj o tym). Oczywiscie to co napisalem jest bardzo szczatkowe. Szczegolowa implementacja bedzie bardziej rozbudowana (ale sadze ze sobie z tym poradzisz, skoro pytasz o taka sytuacje)

A ja dopiszę jeszcze mechanizm event sourcingu. W takim przypadku zamiast przechowywania stanu w bazie przechowujesz zdarzenia, które zaszły w zawiązku z danym produktem. Jest to o tyle wygodne rozwiązanie, że pozwala modelować więcej stanów niż tylko aktualna ilość. Można na liście zdarzeń trzymać informacje o rezerwacjach (włożeniu do koszyka) czy stanie opłacenia zamówienia powiązanego z produktem. Dzięki czemu można znacznie lepiej zaplanować sobie procesy biznesowe. Ale to taki mały dodatek, bo to trochę skomplikowane rozwiązanie.