Jestem trochę zdezorientowany co do mojego podejścia, pracuję nad projektem koszyka i muszę przechowywać koszyk w sesji lub w bazie danych, ale nie jestem pewien, które podejście byłoby najlepsze. Oto przypadek użycia
- Użytkownik nie jest zalogowany i nie dodaje produktu do koszyka (użytkownik anonimowy)
- Użytkownik jest zalogowany i dodaje produkt do koszyka.
Pierwszy przypadek jest dla mnie bardziej mylący, ponieważ może być wiele przypadków, w których użytkownik po prostu odwiedza sklep internetowy i dodaje produkt bez logowania i może być całkiem możliwe, że nie pójdzie do kasy.
Ale nadal musimy utworzyć koszyk dla tego użytkownika, aby utworzyć i zapisać koszyk, mam dwie opcje.
- Dodając produkt, utwórz koszyk w bazie danych i powiąż ten koszyk z tym użytkownikiem. W momencie zalogowania przenieś koszyk do zalogowanego użytkownika.
- Utwórz koszyk, dodaj do niego produkt i zapisz go w sesji, gdy zalogowany użytkownik utworzy koszyk w bazie danych i skojarzy zalogowanego użytkownika z tym koszykiem z użytkownikiem.
Wiem, że zarówno system koszy oparty na bazie danych, jak i oparty na sesjach może mieć zarówno pozytywne, jak i negatywne aspekty, ale nie jestem pewien, które z nich może być najlepsze, biorąc pod uwagę następujące punkty
- Skalowalność
- Elastyczność
- Rozciągliwość
- Aplikacja powinna zadbać o szybkość
Poszukuję informacji na temat tego aspektu w celu ustalenia ścieżki.
źródło
Odpowiedzi:
Wybrałbym rozwiązanie, w którym wszystkim odwiedzającym przy pierwszym wejściu na stronę przypisano unikalny identyfikator. Nie ma znaczenia, czy są anonimowe, czy uwierzytelnione. Podczas rejestracji anonimowi użytkownicy zachowaj unikalny identyfikator.
Przechowuj koszyk w bazie danych. Pamięć masowa jest tania i od czasu do czasu nie powinno być problemu z wydajnością zapytania do koszyka.
źródło
Obie metody mają zalety i wady, ale z mojego punktu widzenia przechowywanie bazy danych ma dwie dość duże zalety.
źródło
Pytanie zakłada, że w ogóle potrzebujesz sesji, które na moim rynku klientów nie są potrzebne. Zdarza mi się prowadzić kilkaset stron eCommerce, a garstka z nich ma duży ruch. Nie używamy nigdy sesji, ponieważ nie są skalowalne, chyba że są farmowane, dlatego są po prostu wolniejsze lub wymagają większej konfiguracji. Sesje zużywają pamięć, a pobieranie danych ze stanu bazy danych jest bardzo wolne i wymaga więcej ruchomych części.
Zamiast tego używamy HTMLS sessionStorage, aby zachować wszelkie informacje o użytkowniku, które musimy pobierać raz za razem, ale bez potrzeby każdorazowej wymiany plików cookie w celu zwiększenia przepustowości. To jest IE8 + i wszystkie inne nowoczesne przeglądarki i urządzenia mobilne są kompatybilne z tą technologią. ALE możesz po prostu przechowywać koszyk w pliku cookie jako rezerwowy, ponieważ tak właśnie zrobiliśmy wcześniej. Oto dobry koszyk z ciastkami: http://simplecartjs.org/
Kiedy użytkownicy logują się lub logują, używamy zaszyfrowanego pliku cookie z wypalonym znacznikiem czasu.
Przechodzimy również w kierunku stosowania ApplicationCache, o ile ma to zastosowanie, co dodatkowo zmniejszy ruch internetowy jako notatkę dodatkową, ponieważ możesz wstępnie pobierać zasoby, a nawet dane katalogowe, dzięki czemu perspektywa użytkownika będzie superszybkim ładowaniem strony internetowej, a urządzenie mobilne będzie również działać offline (bez transakcji). Oczywiście musisz uważać na aktualizację manifestu, gdy zmieniają się produkty itp.
źródło
Zakładasz, że pamięć sesji i pamięć bazy danych są wyłączne. Nie są. Ale zacznijmy od założenia, że są.
Korzyści z przechowywania sesji są trzykrotnie:
Wady przechowywania sesji:
Zalety przechowywania bazy danych:
Wady przechowywania bazy danych:
Nie wspomniałeś o używanej platformie. Chciałbym znaleźć podejście, które wykorzystuje sesję opartą na bazie danych, w której dane sesji istnieją tylko w pamięci w trakcie cyklu żądania / odpowiedzi, ładując je z bazy danych i zapisując z powrotem do bazy danych. W przeszłości dobrze mi to służyło.
Zalety sesji opartej na bazie danych:
Wady sesji opartej na bazie danych:
Istnieje trzecia możliwość, o której ktoś wcześniej wspomniał. Możesz całkowicie zrezygnować z sesji i korzystać z pamięci po stronie klienta, osadzając wszystko w pliku cookie lub w lokalnej pamięci HTML.
Zostawię ci zalety / wady tego ćwiczenia, ale dam ci podpowiedź, że w przypadku przechowywania html5 kompatybilność z przeglądarką może być czymś do dokładnego sprawdzenia.
Przedstawiłem ci fakty. Mamy nadzieję, że pomoże to podjąć właściwą decyzję w danej sytuacji.
źródło
Rozważmy dwa wspomniane przypadki użycia
W takim przypadku zdecydowanie chcesz zapisać informacje o koszyku użytkownika w sesji, aby dobrze służyć użytkownikowi podczas jego sesji. Jeśli zdecyduje się zalogować / utworzyć konto, możesz sobie z tym poradzić na podstawie następnego przypadku użycia. Jeśli on / ona nie zaloguje się, nie musisz wypełniać bazy danych informacjami o tym gościu, ponieważ były one używane tylko do obsługi gościa podczas sesji. Dane te można przetwarzać na zasadzie bezstanowej, tj. Nie stan nie jest zapisywany między sesjami.
W takim przypadku możesz sobie z tym poradzić w taki sam sposób, jak powyżej (oldschoolowe witryny e-commerce), a także dodać te informacje do bazy danych i powiązać z użytkownikiem. Służy to głównie do dostarczania informacji o stanie (stan zapisywany między sesjami), takich jak „Historia przeglądania produktu”, „Zalecenia” itp., Tj. Podobne do Amazon.com.
Rzeczy do przemyślenia:
źródło
Przejdź na sesję, gdy użytkownik nie jest zalogowany. Nawet po zalogowaniu najpierw utwórz koszyk w sesji i zachowaj go w bazie danych tylko wtedy, gdy użytkownik się wyloguje lub upłynie limit czasu sesji.
Musisz sprawdzać liczbę wózków tworzonych w sesji.
źródło