Sesja HTTP lub podejście do bazy danych

16

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

  1. Użytkownik nie jest zalogowany i nie dodaje produktu do koszyka (użytkownik anonimowy)
  2. 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.

  1. 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.
  2. 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

  1. Skalowalność
  2. Elastyczność
  3. Rozciągliwość
  4. Aplikacja powinna zadbać o szybkość

Poszukuję informacji na temat tego aspektu w celu ustalenia ścieżki.

Umesh Awasthi
źródło
2
Dlaczego? Prowadzę kilkaset witryn e-commerce i przechowujemy wszystko w plikach cookie lub localStorage (HTML5). Ponadto sesje zajmują pamięć. Kiedy logujemy się na konto, używamy zaszyfrowanego pliku cookie ze znacznikiem czasu. Nie potrzebujemy sesji, ponieważ kiedy strona się ładuje, używamy technik HTML5 do przechowywania i używania sessionStorage po jednym ładowaniu. Jest to standardowa technologia internetowa zgodna z IE8 +.
Jason Sebring
@LuiggiMendoza ok, dlaczego nie.
Jason Sebring
@ zipstory.com: Chciałbym też rzucić okiem na rozwiązanie oparte na HTML5, ale wciąż nie jestem obsługiwany przez kilka przeglądarek, jestem nieco wątpliwy
Umesh Awasthi
@UmeshAwasthi Przypuszczam, że moi klienci nie dbają o bardzo małą garstkę ludzi w niższych przeglądarkach, ale oczywiście jest to złe podejście, jeśli jest inaczej w twoim ruchu internetowym. Wiem, że wiele krajów korzysta z XP na IE7, a czasem IE6, ale niektóre produkty moich klientów można znaleźć w sklepach takich jak Nordstroms i Macy's itp. Wydaje się, że nie przejmują się tym.
Jason Sebring
@ zipstory.com: Pracuję z aplikacji eCommerce, gdzie klient ma jeszcze wsparcia dla IE6, co teraz powiesz ABT nim :)
Umesh Awasthi

Odpowiedzi:

9

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.

Jakob Gade
źródło
a kiedy muszę wyświetlić stronę ze szczegółami koszyka? czy powinniśmy przechowywać / pobierać dane z sesji, czy szukać bazy danych?
Umesh Awasthi
Jeśli przechowujesz dane koszyka w bazie danych, to tak, musisz trafić do bazy danych.
Jakob Gade
7

Obie metody mają zalety i wady, ale z mojego punktu widzenia przechowywanie bazy danych ma dwie dość duże zalety.

  1. Raportowanie Nie możesz zgłaszać porzuconych koszyków, współczynników konwersji itp., Jeśli dane są w sesji.
  2. Limit czasu sesji. Byłbym zirytowany, gdybym poszedł zjeść obiad i wrócił, by zobaczyć, że mój wózek został opróżniony, ponieważ sesja wygasła. Wyobrażam sobie, że sprzedawcy też by się to nie spodobało. Chcemy nakłaniać użytkownika do kupowania, a nie do rezygnacji i odejścia.
Jason P.
źródło
6

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.

Jason Sebring
źródło
4

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:

  1. Nie ma potrzeby jawnego wstawiania danych do bazy danych. Po prostu ustaw zmienną sesji i gotowe. Prosty i funkcjonalny o niskim ryzyku.
  2. Nie musisz zarządzać cyklem życia wizyty użytkownika i koszyka, ponieważ pojemniki / ramy robią to za Ciebie
  3. Zwykle wykonuje się automatyczne czyszczenie starych bezczynnych sesji.

Wady przechowywania sesji:

  1. Powinowactwo sesji, chyba że zbadasz replikację
  2. Bez przełączania awaryjnego, chyba że zbadamy replikację lub ręczne utrzymywanie stanu sesji na dysku, co może się skomplikować.
  3. Wszystkie sesje muszą być przechowywane w pamięci. Jest to wzmocnione, jeśli zastosujesz replikację.

Zalety przechowywania bazy danych:

  1. Nie musisz się martwić koligacją sesji lub replikacją stanu. Możesz okradzić wszystkie żądania.
  2. Mniejszy narzut pamięci w aplikacji.
  3. Jeśli zamówienie zostanie zakończone, wszystko i tak trafi do bazy danych, więc może to ułatwić wykonanie, ponieważ dane są już obecne.

Wady przechowywania bazy danych:

  1. Opuszczone wózki - jakiś anonimowy użytkownik dodał przedmiot do koszyka i zniknął. Te dane pozostają na zawsze, chyba że masz jakiś proces wygasania.
  2. Musisz wymyślić sposób śledzenia użytkowników i dowiedzieć się, czy dla danego żądania reprezentuje to istniejącą lub nową sesję przeglądania. (tak, prawdopodobnie jest to łatwe, jeśli używasz pliku cookie, ale jak zapewnić, że dwóch użytkowników nie otrzyma tego samego identyfikatora?).
  3. Więcej kodów

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:

  1. Nie ma potrzeby koligacji serwera.
  2. Łatwo w pamięci serwera aplikacji
  3. Dane o bezczynnej / porzuconej sesji są dla Ciebie usuwane.
  4. Cykl życia pierwszej wizyty użytkownika, ponownej wizyty, zakończenia sesji jest dla Ciebie wymyślony.
  5. Łatwy do kodowania

Wady sesji opartej na bazie danych:

  1. Konfiguracja - musisz zbadać swój kontener, czy jest to PHP, Java EE (Tomcat, Jetty, JBoss itp.), Node.js + express.js lub co nie obsługuje tego i dostarcza odpowiednią konfigurację.
  2. Może być konieczne załadowanie tego testu, ponieważ dodajesz 2 operacje bazy danych na żądanie.

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.

Brandon
źródło
Straciłeś przewagę związaną z przechowywaniem bazy danych, umiejętnie organizując się, aby analizować stawki zakupu rzeczy umieszczonych w koszykach.
HLGEM
@HLGEM Doskonały pomysł - nigdy o tym nie myślałem!
Brandon
Myślę o tych rzeczach, ponieważ to ja przeprowadzam analizę danych w bazie danych. Projektując bazy danych, jednym z pierwszych pytań powinno być, do czego będziemy potrzebować tych danych i prawie nikt ich nie pyta.
HLGEM
3

Rozważmy dwa wspomniane przypadki użycia

Użytkownik nie jest zalogowany i nie dodaje produktu do koszyka (użytkownik anonimowy)

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.

Użytkownik jest zalogowany i dodaje produkt do koszyka.

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:

  • Czy konieczne jest zapisywanie danych?
  • Jeśli tak, jakie dane należy zapisać, aby lepiej służyć użytkownikowi?
  • Skalowalność + przechowywanie danych - Jak zapiszesz informacje o koszyku w celu szybkiego wyszukiwania w bazie danych w celu obsługi wielu użytkowników?
GeekByte
źródło
3
Pomaga także firmie analizować sprzedaż. Jak często produkt jest wkładany do koszyka, ale nie kupowany. Jeśli wartość procentowa jest wysoka, mogą chcieć przyjrzeć się prezentacji produktu lub cenie, aby sprawdzić, czy zmiany mogą pomóc w poprawie stopy kupna. Zapisywanie może również pozwolić użytkownikowi szybko zobaczyć te przedmioty, jeśli nie zamówi ich w dniu, w którym szukał, niż poszukać ich ponownie. Może więc umieściłeś je w koszyku, ale chciałeś poczekać do jutra (dzień wypłaty), aby je faktycznie kupić. Zapisywanie danych może więc spowodować, że Twoi prawdziwi klienci będą kupować więcej rzeczy.
HLGEM
Ale ostatecznie jest to problem z określeniem wymagań i powinieneś powiedzieć swojej firmie, co planujesz zrobić, i upewnić się, że jest to, czego oczekują, zanim cokolwiek zbudujesz.
HLGEM
Pamiętaj, że musisz pomyśleć o zamówieniu i koszykach z perspektywy tego, czego firma może potrzebować w przyszłości. Jeśli chcą analizować dane, najlepiej je przechowywać. Programiści rozłączają się przy interfejsie użytkownika i zapominają o celu danych podczas przechowywania.
HLGEM
@HLGEM: Bardzo dobra uwaga! Odpowiedziałem na to pytanie jedynie w oparciu o potrzebę obsługi funkcji samochodu dla użytkownika-gościa w porównaniu z członkiem witryny. Z biznesowego punktu widzenia powinien istnieć osobny system statystyk, który jest zależny od pewnego rodzaju systemu baz danych, który śledzi produkt (y) pod względem geograficznym, liczby użytkowników, powiązanych produktów, kupowania kontra odrzutów itp.
GeekByte
0

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.

Sudhanshu Umalkar
źródło