Cześć, zastanawia mnie jak w sklepach internetowych przechowywane są informacje o zamówionych produktach (dodanych do koszyka), ale bez logowania użytkownika.

Największy problem tkwi w tym że podczas dodawania produktu może mieć on inne opcje np: sok może być jabłkowy, malinowy itp, oraz może mieć różne wielkości (zakładając że sok z opcjami to 1 produkt, a nie kilka).
Specjalnie podaje taki przykład

Ja myślę o dwóch metodach:

1. ciastko odwołujące do bazy danych z przedmiotami w koszyku (niezmieniane rekordy usuwanie co np: 5 dni)
2. ciastko przechowuje wszystkie informacje w postaci np: 1,7,5;2,8,9; (czyli id produktu, id smaku, id wielkości)

Proszę o jakieś porady jak to jest realizowanie.

Jeden sklep nad którym pracowałem używał metody 1 - użytkownicy, którzy nie pojawili się ponownie po 14 dniach byli usuwani z bazy.

Dzięki za odpowiedź. Kolega sugerował by jednak trzymać w ciastkach bo po co zaśmiecać bazę danych.

Proszę o więcej porad

w ciastku powinien imo być tylko id sesji a wszystkie dane powinny być trzymane w sesji (czyli domyślnie w plikach lub lepiej w bazie danych)

1. ciastka są przesyłane za każdym razem do serwera (nawet przy zapytaniach o grafikę, skrypty i arkusze css) więc przy dużej liczbie produktów mogą niepotrzebnie zapychać łącze (może być istotne dla klientów korzystających z danych pakietowych) / obciążać serwer
2. użytkownik może po swojej stronie modyfikować ciastka, mogą się więc pojawić luki bezpieczeństwa i trzeba wprowadzić mechanizmy walidujące dane - prawdopodobnie zwiększy się liczba zapytań o produkty do bazy danych
3. sesja może być przypisana do konta - ktoś może się zalogować gdzieś indziej i kontynuować zakupy. w przypadku trzymania wszystkiego w ciachach nie ma takiej opcji
4. może się zdarzyć że podczas zakupów zmienia się cena produktu, wtedy użytkownicy którzy zdążyli dodać już produkt do koszyka mogą przez jakiś czas kupić produkt po starej cenie a reszta po nowej. Trzymając dane w ciastkach musiałbyś przechowywać godzinę w której produkt został dodany do koszyka więc: a) musiałbyś w bazie trzymać historię cen żeby powiązać je z godziną; b) użytkownik mógłby łatwo zafałszować te dane i kupić produkt po lepszej cenie
5. w każdej chwili masz informację ilu użytkowników ma coś w koszyku, co to są za rzeczy itp. możesz prowadzić złożone statystyki - jeżeli chciałbyś to robić wykorzystując ciacha to i tak musiałbyś trzymać kopię wszystkiego w bazie danych. Na tej podstawie też (patrz pkt.5) możesz zmieniać cenę produktu (ktoś ma rzecz w koszyku = jest dostępna jedna sztuka mniej = cena się zwiększa; po wygaśnięciu sesji [i zrezygnowaniu z produktu], cena wraca do poprzedniego stanu - tak się często dzieje na stronach gdzie rezerwuje się bilety lotnicze)

Ogólnie mówiąc to mnie przekonałeś do trzymania informacji w bazie. Tylko kilka kwestii:
2. Wiem o możliwości edycji ciastek, więc porobiłbym sprawdzenia.
3. Mówimy tutaj o trzymaniu informacji dla osób niezalogowanych. Jak ktoś się zaloguje to dane są przepisywane na użytkownika (czyli są w bazie).
4. Cena jest taka w jaką kliknie użytkownik, a ciastka byłyby usuwane co np: 10 dni. W dodatku od strony prawnej kupno czegokolwiek w internecie nie jest umową.

Jednak informacje o osobach niezalogowanych też będę trzymał w bazie.

xyz napisał(a)

W dodatku od strony prawnej kupno czegokolwiek w internecie nie jest umową.

Nie znam się na prawie, ale na allegro ponoć (pomijając parę działów) klikając "Kup Teraz" wiążesz się umową. Chyba, że to w regulaminach trzeba napisać, że kupno to umowa.

A i tak chodziło tu raczej o to, że użytkownik po prostu będzie niezadowolony, jeżeli "zaklepie" sobie towar po niższej cenie, a tu dostanie maila, że była aktualizacja cen i ma dopłacić 80zł.

Jeszcze jedno,
jeżeli zamówienia trzymam w bazie (userów zarejestrowanych Z i niezarejestrowanych NZ) to podzielić to na 2 tabele ? Czyli w jednej będą zamówienia osób Z, a w drugiej NZ i jak ktoś z NZ zarejestruje się to przeniosę to do bazy Z.

Minus tej opcji to dodatkowe operacje usuwania danych z tabeli NZ i dodawanie do Z.

Opcja 2:
Jest jedna baza dla Z i NZ.

Minus drugiej opcji jest taki że częste usuwanie rekordów.

Strasznie trudna analiza przypadku.
Usuwanie z jednej tabeli:

DELETE.

Prznoszenie między dwoma tabelami:

1. SELECT - wyszukuje rekordy do przeniesienia.
2. INSERT - kopiuje rekordy do tabeli Z.
3. DELETE - usuwam rekordy z tabeli NZ.
   Co więcej, nie spotkałem się jeszcze z stuacją, w której dwie tabele zawierające praktycznie to samo były lepsze od jednej.

Minus drugiej opcji jest taki że częste usuwanie rekordów.

A mogę zapytać, po co w ogóle chcesz cokolwiek usuwać? Pomyliłeś chyba zamówienie z koszykiem (który przechowuje się po stronie użytkonwnika?).
Zapychanie łącza przez ciasteczka. Maksymalny rozmiar na jedno ciasteczko to 4KB, więc tym bym się nie martwił. W ciasteczku nie będze przecież przechowywana pełna informacja o produkcie ale tylko, powiedzmy, id w bazie danych oraz atrybuty (id => wartość).
Dla użytkowników zalogowanych możesz wprowadzić koszyk w bazie danych.

jakiej platformy sklepowej używasz ?

Siema,
pisze swój. Też sądzę że opcja 1 tabeli jest lepsza, ale wolałem zapytać. W dodatku wszystko będę trzymał w bazie, a ciastko ma tylko informacje o id rekordu.