Forum PHP.pl

@Niktoś: SQLSpaces nie jest nierelacyjną bazą danych. SQLSpaces to implementacja tuple space bazująca na relacyjnych bazach danych, przy czym domyślnie korzysta z HSQL, a dodatkowo może korzystać z MySQL, czy PostgreSQL.
Tuple space natomiast to implementacja paradygmatu pamięci asocjacyjnej dla obliczeń równoległych/rozproszonych. Tuple space może być rozumiana jako rozproszona pamięć współdzielona.

Ogólnie rzecz biorąc, raczej średnio (żeby nie rzec, że w ogóle nie) nadaje się to do implementacji koszyka użytkownika.

Osobiście oparłbym implementację sklepowego koszyka o mechanizm sesji, a dodatkowo umożliwiłbym użytkownikowi podejmowanie decyzji, czy przechowywać te dane, czy też nie (a tu z pomocą przychodzą zarówno ciasteczka, jak i system baz danych, w zależności od tego, jaką decyzję podejmie użytkownik, przy czym poinformowałbym go również co się stanie, jeśli nie podejmie żadnej decyzji).

Ten post edytował mortus 6.05.2012, 23:37:33

Ale żeś mi armatę wystawił, chyba najgorszy atak na sesję, przed którym trudno się uchronić.Nawet Facebook,google(widziałem na filmiku włam na poczte) sobie nie radzą ,a mają przecież ekspertów przy których ja się chowam.

Mam ,na to pomysł- oprócz SSL, zaimplementować dodatkowo (IPsec), może uchroni.


Można wiedzieć dlaczego tak sądzisz?
Nie wiem dlaczego wiki sklasyfikował Turple Space do grupy NoSQl-czyli tych nierelacyjnych,a w liście relacyjnych baz danych tej bazy nie ma,zaś samo HSQLDB jest?Nie wiem jakaś hybryda to.
http://en.wikipedia.org/wiki/NoSQL
Zobacz na listę poniżej.
Key-value cache in RAM

Tuple space
Velocity //Nowsza wersja AppFabric?Zarówno jedno i drugie to nakładki/narzędzia na bazy danych?

Sugerowałem się tą listą, ale doczytałem solidnie i faktycznie relacyjna, oparta na HSQLDB, która napisana jest w javie a dane przetrzymuje w pamięci RAM.Choć naprawdę nie dostrzegam tam klucza głównego i relacji między tabelami.

Ten post edytował Niktoś 7.05.2012, 01:21:15

Szczerze mówiąc to nie rozumiem Twojej uwagi, jeżeli zagłębisz się odrobinę w tematykę zabezpieczenia sesji to odkryjesz, że oprócz tego ssl'a jest jeszcze kilka technik i praktyk, które częściowo zabezpieczają oraz redukują szkody powstałe w wyniku przechwycenia sesji. A skoro korzystasz z sesji to chyba warto się dowiedzieć jak ją zabezpieczyć.

Zrobienie tego w sesji jest po prostu głupie. Nikt z takiego sklepu nie będzie chciał korzystać (firma, właściciel sklepu) ponieważ odbierasz w ten sposób możliwość analizy rynkowej, i nie masz wglądu jakie towary zostają porzucone, na jakim etapie. Bez takich danych nie przeprowadzisz żadnej analizy. Gdy budujemy na bazie danych to jeśli jest ona dobrze zrobiona to możemy nawet zebrać informacje o stronie. Na przykład gdy porzucenia koszyka kończą się na formularzu wysyłania to być może proces wysyłki jest opisany niezrozumiale, albo nie jest wygodny i to jest znak że trzeba coś zmienić. Tak już działa rynek.

Chcesz robić sesje? Twoja sprawa, ale nikt poważny się tym nie zainteresuje.

Pozdrawiam

Ten post edytował spokoloko123 7.05.2012, 06:07:17

spokoloko123 w jaki sposób chcesz to zrobić, jeśli nie w oparciu o sesje?

Niektórzy dyskutanci słusznie od początku wątku zwracają uwagę na fakt, że HTTP jest protokołem bezstanowym.
W celu zachowania stanu jakichkolwiek danych między żądaniami musisz napisać własną implementację sesji.

SQLSpace to nie baza danych, a jedynie interfejs/łącznik pomiędzy przestrzenią tupletów (tak brzmiałoby chyba dosłowne tłumaczenie zwrotu tuple space), a systemem zarządzania relacyjną bazą danych. Domyślnie systemem tym jest HSQLDB, który przechowuje dane w pamięci operacyjnej. Można jednak skonfigurować HSQLDB tak, by przechowywał dane w pliku. Użytkownik korzystający z SQLSpace może w tej chwili wybrać, z którego RDBMS-a chce korzystać, przy czym dotychczas zaimplementowano wsparcie tylko dla HSQLDB, MySQL i PostgreSQL. Zauważ przy tym, że bazy danych MySQL i PostgreSQL mogą również rezydować tylko i wyłącznie w pamięci operacyjnej.
Same przestrzenie tupletów możemy zakwalifikować do noSQL-owych baz danych, gdyż umożliwiają one przechowywanie danych postaci klucz - wartość w pamięci operacyjnej i nie wymagają od nas definiowania jakichkolwiek relacji. Jednak SQLSpace to tylko i aż implementacja tuple space.

Być może pospieszyłem się z oceną przydatności SQLSpace do implementacji sklepowego koszyka, jednak uważam, że używanie tak potężnego "narzędzia" do realizacji tak "błahych" mechanizmów mija się z celem. Przede wszystkim należy pamiętać, że SQLSpace działają na zasadzie rozproszonej pamięci współdzielonej, z czego wynika fakt, że może być wykorzystywana jednocześnie przez setki różnych systemów, być zlokalizowana w wielu pamięciach operacyjnych na raz a jej celem jest zapewnienie ujednoliconego interfejsu wzajemnej wymiany danych pomiędzy wspomnianymi systemami. "Zaprzęganie" SQLSpace do realizacji koszyka na zakupy wydaję się być lekkim nadużyciem, tym bardziej, że możliwość przechowywania danych tylko w pamięci operacyjnej, zapewniają nam już same RDBMS-y.

@spokoloko123: A co ma koszyk wspólnego ze zbieraniem informacji na temat tego, na którym etapie użytkownik wycofał się z dokonania zakupów? Co najwyżej można ten koszyk wykorzystać, do analizowania informacji jakie produkty chciał użytkownik nabyć. Wątpię, aby sesje miały w tym przeszkadzać. Poza tym analizowanie takiej informacji bez wiedzy i zgody użytkownika stanowi poważne naruszenie praw konsumenta. No chyba, że będą to dane w 100% anonimowe, a użytkownik zostanie wcześniej poinformowany o tym, że jego zakupy będą "śledzone". W przeciwnym przypadku wymagałoby to wcześniejszej rejestracji użytkownika i zaakceptowania przez niego odpowiednio sformułowanego regulaminu.

Ten post edytował mortus 7.05.2012, 09:24:19

No chyba jasno się wyraziłem. Tworzysz sobie tablice, a użytkowników owszem rozpoznajesz po session_id, ale wszystko i tak pozostaje w bazie. Po tym jak porzuci koszyk to on dla użytkownika przestaje istnieć, ale ty wiesz, że masz to w bazie i poddajesz to analizie. A gdy kupuje faktycznie i dokonał wpłaty, czy ogólnie zamówienie zostało złożone to przenosisz z tej tabeli "koszyka" do tabeli realizacji zamówień.



Nie przyszło ci do głowy, że w tabeli nazwijmy ją "koszyk" można stworzyć kolumnę, która zbiera informacje na jakim etapie się znajdujemy? Na etapie samego dodawania jest lvl 1 - załóżmy, a w kolejnych inkrementujemy tę wartość. Trochę wyobraźni (IMG:style_emoticons/default/wink.gif) . Żadne śledzenie tylko do numeru id sesji masz przypisane do jakiego etapu użytkownik doszedł. Żaden regulamin do tego potrzebny nie jest.

Ten post edytował spokoloko123 7.05.2012, 08:23:23

No i po co mi do tego baza danych? Przecież równie dobrze mogę sobie taką informacje zapisać w sesji. Piszesz, że chcesz identyfikować etap dokonywania zakupów, poprzez dodatkową kolumnę w tabeli koszyka, ale gdy użytkownik zdecyduje się na zakup i go dokona, albo przynajmniej złoży zamówienie, to czy konieczne jest dalsze przechowywanie informacji o zawartości koszyka w tabeli koszyk? Odpowiem - NIE. Tracisz zatem informację na temat tego, na jakim etapie użytkownik wycofał się z ewentualnego dokonania zakupu. Choć tak naprawdę odpowiedzialność za tę część analizy rynkowej (jak to ładnie nazwałeś) przejmuje moduł realizacji zamówień. Informacja o tym na jakim etapie użytkownik wycofał się z dokonywania zakupów nie ma nic wspólnego z zawartością koszyka, a jeśli ma podlegać analizie, to powinna być zapisywana w zupełnie odrębnej/ych tabeli/ach, która/e "gromadzi/ą" wszystkie dane podlegające takiej analizie.

PODSUMOWUJĄC:
- koszyk na zakupy powinien bazować na sesji,
- jeśli użytkownik musi odejść od komputera na czas dłuższy, aniżeli czas życia sesji, to powinien mieć możliwość zapisania zawartości koszyka do bazy danych lub w ciasteczku,
- jeśli użytkownik zdecyduje się zapisać zawartość koszyka w ciasteczku, to warto go poinformować, że gdy usunie ciasteczka, straci zawartość koszyka (ta opcja często jest pomijana, a domyślnie zawartość koszyka zapisywana jest w ciasteczku o długim czasie życia),
- zapisanie zawartości koszyka w bazie danych wiąże się z nadaniem odpowiedniego identyfikatora dla tego koszyka (może wymagać rejestracji użytkownika, ale nie musi, i nie może być identyfikowane przez id sesji, bo sesja w czasie nieobecności użytkownika może wygasnąć),
- do analizy rynkowej należy użyć odrębnego modułu wykorzystującego dane przechowywane w tabeli bazy danych, sesji lub innej pamięci, przy czym dane do tej analizy mogą być dostarczane przez aplikację (każdy moduł raportuje dane do analizy samodzielnie, korzystając jednak z tego samego/unikalnego identyfikatora, jakim może być id sesji), czy system baz danych (np. triggery, które automatycznie dokonują odpowiednich wpisów do bazy danych w zależności od tego, jaką akcję podejmie użytkownik - opuszczenie koszyka (równoważne de facto usunięciu odpowiedniej zawartości z sesji, bazy danych, czy innej pamięci), wycofanie zamówienia, brak wpłaty w określonym terminie, itp.).

Ten post edytował mortus 7.05.2012, 09:54:29

Może być identyfikowane przez id sesji używając przy tym cookies do podtrzymania sesji jak np.ja zrobiłem.

Czytałem o HSQLDB i jest kilkakrotnie szybsza niż PostreSQL-zostawię tą implementacje, gdyż sama waga tej bazy jest bardzo lekka(silnik 100kb) a dostęp do danych szybki.

Kurcze chciałem nierelacyjną ,a mam relacyjną bazę danych przez nieporozumienie z TupleSpace .Potrzebowałem narzędzia do przechowywania key value pairs.Początkowo zaimplementowałem Redisa ,ale na windowsie to jest na cygwinie i to zniechęciło mnie(cygwiny są mało stabilne,i kiepsko wyglądają).Dlatego wybór padł na SqlSpaces, który wydawał mi się dość podobny w sposobie działania i nieoparty na cygwinie.

Są lepsze narzędzie jak AppFabric, ale zaimplementować nie mogłem ze względu na OS. Mam nadzieje ,że wybór był dobry, ale to się okaże.

Pamiętaj tylko, że cookies można usunąć.

Nie doczytałem o PostgreSQL, ale najszybciej SQLSpaces działa z MySQL, przynajmniej taką informację znalazłem na stronie projektu.

Już sama nazwa, która zawiera w sobie akronim SQL sugeruje, że dotyczy "to" relacyjnych baz danych. Zresztą tutaj i tak lepszym rozwiązaniem będzie relacyjna baza danych, ponieważ pomiędzy produktami a zawartością koszyka, jakaś relacja jednak istnieje. Co więcej najlepiej/chyba najwydajniej by było zrealizować wszystko w jednym systemie baz danych.

Ten post edytował mortus 7.05.2012, 09:45:32

@mortus
Nie rozumiesz zasad e-commerce. Nie będę tego tłumaczyć 2 raz. Analiza rynkowa nie jest dokonywana na podstawie tego co jest w koszyku tylko an tym co zostało kupione. Ehhh... A po tym gdzie proces zakupów został przerwany jest ważne z kilku powodów i możemy w ten sposób dowiedzieć się czy np warunki przesyłki mu nie odpowiadały, może nie wszystko jest napisane jasno i miał wątpliwości, może okres realizacji zamówienia był za długi itd. itp.

Ten post edytował spokoloko123 7.05.2012, 18:58:42

To Ty kolego nie rozumiesz, że nijak się to ma do implementacji koszyka na zakupy. Informacja o tym, co zostało kupione powinna się znaleźć w tabeli zamówień zrealizowanych, a informację o tym, w którym "miejscu" użytkownik odstąpił od dokonania zakupu powinien przesyłać sam system, a nie konkretnie koszyk na zakupy. Zauważ, że jeśli użytkownik dokona zakupu, to przechodzi do modułu odpowiedzialnego za realizacje zamówień, jeśli wycofa się w tej chwili, to właśnie ten moduł powinien raportować, że użytkownik wycofał się z realizacji zamówienia. Tak na dobrą sprawę powodów, dla których użytkownik "napełnił" koszyk i zostawił może być mnóstwo i możemy tylko przypuszczać, dlaczego postąpił on tak, a nie inaczej. Wątpię aby te dane były przydatne z punktu widzenia Twojej analizy rynkowej. Inaczej ma się sprawa zamówień na produkty, które już są w koszyku (kolejny, że tak to nazwę, krok podczas zakupów). Tutaj wykorzystujemy implementację koszyka tylko do pobrania informacji o produktach, które użytkownik do koszyka "wrzucił" i tyle. Resztą zajmuje sie moduł obsługi zamówień. Zrozum wreszcie, że są to dwie różne "rzeczy".

Ten post edytował mortus 7.05.2012, 19:18:42

@spokoloko123 pomysł bardzo fajny, ale i tak ten kosz warto zrobić na sesji, a w bazie rejestrować zmiany kosza. Chociaż realizując Twoją koncepcję warto by zrobić coś bardziej rozbudowanego, ponieważ samo zapisanie kosza to marne narzędzie analityczne. Co Ci daje informacja, że ktoś zrezygnował mając mp3player'a w koszyku? Jeżeli chcemy na poważnie analizować utraconych klientów to warto by rejestrować wszystkie kroki tego klienta na naszej stronie, czyli nie tylko co dodał, ale też co oglądał i całą drogę jaką dany klient przebył w serwie, skąd zaczął, a gdzie skończył. Wydaje mi się, że takie narzędzie do analizy to zupełnie odrębny i o wiele bardziej zaawansowany temat. Ponadto tego typu dane nabierają wartości raczej przy dużym ruchu na stronie, małej ilości danych nie da się poddać rzetelnej analizie.

Taka analiza ma tylko i wyłącznie sens w przypadku użytkowników, którzy dokonali wcześniej rejestracji.

To zależy, co chcemy analizować. Bo jeśli np. badamy, czy asortyment jest wystarczający (tzn. umożliwia zadowolenie większości potencjalnych klientów) to musimy rejestrować większość ruchów użytkownika, o czym pisał tehaha, np. to po jakich kategoriach się poruszał, jakie produkty dodawał do koszyka, czy z niego usuwał, czy w ogóle coś dodawał i usuwał. Tutaj nie ma potrzeby zakładania konta, czy rejestrowania się i użytkownik nie musi wiedzieć, że go "obserwujemy" dopóki jest on użytkownikiem anonimowym. Jeśli analizujemy "sprawność" systemu, to musimy zapisywać i analizować informacje, o jakich pisał spokoloko123, czyli to, czy użytkownik zrezygnował z zakupu, na jakim etapie wtedy był, czy może jednak zdecydował się dokonać zakupu, a może nie odpowiadał mu sposób dokonywania płatności, itd.. Im więcej danych zbierzemy, tym dokładniejsza i bardziej wiarygodna będzie analiza.

Ogólnie jest to tak szerokie zagadnienie, że można by książkę napisać, albo więcej książek. Jednak nadal przekonuję, że nijak ma się do sposobu implementacji sklepowego koszyka.

Edycja:
Poza tym to off-top.

Ten post edytował mortus 7.05.2012, 19:51:43

No ale jeśli użytkownik nie będzie zarejestrowany,to wobec czego będziecie go kojarzyć(jest anonimowy jak nazwa wskazuje),po Ip (jest zmienne),DNS(także zmienne),User Agent(może korzystać z różnych browserów)?Może dodać koszyk usunąć, zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu, a ty dostaniesz dwie różne statystyki tego samego użytkownika w rezultacie czego statystyki będą odzwierciedlały fałszywy obraz.
Jedyne co mi na myśl przychodzi to budowanie statystyk dla anonimowego użytkownika na podstawie coocies, ale to chyba byłoby wariactwo.

Ten post edytował Niktoś 7.05.2012, 20:00:21

Oczywiście jeśli użytkownik się zarejestruje, a co więcej poda swój wiek, to przyczyni się do tego, że analiza będzie bardziej szczegółowa. Będzie można np. określić grupę docelową dla produktów z danej kategorii.
Natomiast każdy ruch użytkownika, czy to dodanie przedmiotu do koszyka, czy przejście do kategorii to nic innego jak wywołanie żądania obsługiwanego przez określony moduł systemu i każdy taki moduł "zobowiązany jest do raportowania swojego stanu". Te informacje zapisujemy w bazie danych i poddajemy analizie.

Ten post edytował mortus 7.05.2012, 20:06:46

@Niktoś identyfikacji użytkownika pomiędzy żądaniami dokonujesz na podstawie ID sesji
Oczywiście, że tak może być, każde badanie statystyczne jest obciążone błędem pomiaru i zawiera "obserwacje odstające", nie istnieje idealne badanie, które przedstawi 100% rzeczywisty obraz sytuacji. Aczkolwiek tego typu badanie i tak będzie wartościowe, ponieważ po pierwsze niewiele kosztuje w porównaniu do innych metod badawczych bo drugie statystyki są gromadzone w sposób ciągły i przy dużych ruchu można wyciągnąć bardzo wiele wniosków i obserwować zmiany po ulepszeniach i zmianach w serwisie.

Tak czytam i aż mnie dziw bierze jak bardzo ludzie nie rozumieją o co chodzi w sesjach. Sesje to nasz pośrednik pomiędzy klientem i serwerem w bezstanowym protokole HTTP. Aby móc powiązać te dane potrzebujemy:
- utworzyć identyfikator sesji (SID czy jakkolwiek go sobie nazwiemy)
- gromadzić dane sesji

Sesje implementujemy po stronie klienta za pomocą:
- doklejania parametru sesji (SID) do adresu (jeżeli nie ma obsługi np cookies)
- za pomocą cookies
- można się ewentualnie pokusić o local storage (choć nie wiem czy ktoś tak aktualnie robi, są rozwiązania w JS wykorzystujące różne handlery w zależności od technologii którą klient wspiera) tyle że też nowoczesne przeglądarki ze wsparciem ogółu technologii zwanych HTML5 otwierają ogromne pole do popisu dla włamów
Po stronie klienta możemy trzymać albo sam SID, albo jakieś dodatkowe, tymczasowe dane ale nic ważnego (ciastko można skasować, można je zmienić, wirus może próbować je odczytać albo zmienić).

Oraz po stronie klienta za pomocą dowolnego mechanizmu przechowywania. Może to być:
- relacyjna baza danych
- nierelacyjna baza danych
- pliki tekstowe
przy czym rozwiązania te są zupełnie niezależne od naszej implementacji sesji a zależą od dostępności technologii i wymagań projektu. Jak ktoś wcześniej zauważył można nawet podmontować obszar pamięci jako katalog i obsługa operacji na danych jest zrzucona na system operacyjny (kernel, który we wszystkich rozwiązaniach i tak pośredniczy, to tak off-topicowo).
Tutaj, z racji tego że klient dostępu do tych danych nie ma, przechowujemy dane ważne. Tyle że rozwiązania te muszą być zabezpieczone przed typowymi próbami nieupoważnionego dostępu jak choćby SQL Injection czy inne wymienione w wątku.

W obu przypadkach od nas zależy co przechowujemy w tych implementacjach ponieważ każde z nich ma jakieś ograniczenia. Cookie do 4kB, relacyjne bazy danych mogą być wolne (ale nie przesadzajmy, przy ilości zapytań potrzebnych do obsługi całego sklepu to pryszcz dla silnika), trzymanie w pamięci może sprawić że dane stracimy.

Sam mechanizm sesji to całkowicie nasza inicjatywa bo akurat w tym przypadku można skorzystać z gotowych, dostępnych w PHP metod ale też napisać klasę która nic z SessionHandler czy interface nie implementuje. Chodzi tylko o to żeby powiązać SID klienta z SID serwera. Co więcej, można nawet napisać taki mechanizm, który dla danych mniej istotnych tworzy namespace pracujący w backendzie na noSQL a dla danych istotnych dla baz relacyjnych.

dla jednego browsera: permanent cookie, panopticlick
sytuacja "zamknąć browser, otworzyć inny browser i dokonać zakupu tego samego przedmiotu" jest możliwa ale marginalna (ZU trzyma się jednej przeglądarki)