Witam. Jakie są wasze sposoby, aby bez żadnego FW poprawnie wykonać taką funkcję. Załóżmy że robimy sklep internetowy, i mamy funkcjonalność, która finalizuje zrobienie zakupów. Po przyciśnięciu przycisku 'zrealizuj' funckja ma przenosić produkty do tabeli kupione i sprzedane, oraz usuwać te produkty z tabeli dodane, czy zamiast tworzenia osobnych zapytań 2x INSERT i 1x DELETE, jest jakiś inny sposób, aby zawrzeć te pytania w jednym?
Korzystam z php Data Object, może ta biblioteka ma coś co to umożliwi?
0
0
Lepiej to co w koszyku trzymać np. w sesji, a nie w tabeli. Co do KUPIONYCH oraz SPRZEDANYCH to widzę, że musisz poczytać trochę o normalizacji baz danych bo nie powinieneś trzymać tych samych informacji w różnych tabelach.
Dodatkowo też jeżeli była np. jedna płatność za kilka produktów to też nie powinno się powielać takiej informacji tylko rozbić to na kolejne tabele (zadanie domowę doczytać o normalizacji i bazach danych :P ).
Wracając do pytania: Czy jest jakiś sposób na zawarcie tego w jednym zapytaniu?
Możesz zrobić też tak, że koszyk stworzysz jako samodzielny obiekt, który będziesz trzymał w sesji dla danego użytkownika, a po dokonaniu płatności wrzucisz jego zserializowaną postać do tabeli razem z informacją kto go kupił i kiedy.
Taki koszyk oprócz swoich metod (trzyma np. logikę dodawania i usuwania przedmiotów) zawiera też podstawowe informację o produktach do niego dodawanych czyli ID produktu, tytuł i cenę.
Dzięki temu możesz np. później obniżyć cenę jakiegoś produktu w bazie danych, a wyświetlając sobie już kupione przedmioty będziesz miał dostęp do cen jakie były w chwili ich zakupu.
Eliminuje to też jakieś tam archiwalne tabele i związane z nimi kolejne zabawy przy normalizacji.
0
Wszystko ok. Lecz jak wtedy do sesji przypisać te same zmienne ($produkt), ale z innymi parametrami ?
0
Z tego co wiem to sesja ma ograniczoną ilość znaków, więc nie bardzo się nadaje do tego. Bo jak klient będzie chciał przypisać do koszyka 50 produktów? to jak to pomieści sesja?
0
W sesji trzymasz cały obiekt koszyka z jego zawartością. To co w nim jest możesz np. trzymać w tablicach asocjacyjnych gdzie jako klucz dajesz ID produktu z bazy, a w wartości kolejną tablicę asocjacyjną z interesującymi Cię wartościami (cena, ilość danego produktu etc) i jako wartości podajesz bieżące dane.
Następnie przy finalizacji zakupów wszystko to serializujesz i wsadzasz w bazę wraz z resztą potrzebnych informacji (id_kupującego, id_platnosci).
Możesz potem to odserializować i wyświetlić informacje tam zapisane w historii zamówień oraz dać link do aktualnej strony z produktem i jego pełnym opisem na podstawie zawartych tam ID.
Co do wielkości sesji:
http://stackoverflow.com/questions/4649907/maximum-size-of-a-php-session
0
A masz może jakiś pomysł jak zoptymalizować tę funkcję w której jest dużo zapytań? i nie wszystkie się wykonują ?
$stmt=$this->db->prepare("UPDATE kategoria SET ilosc=:ilosc WHERE id = :id");
$stmt->bindParam(':id',$id);
$stmt->bindParam(':ilosc',$ilosc);
$stmt->execute();
//Klient kupuje produkt (przenoszony zostaje do tabeli Kupione)
$stmt=$this->db->prepare('INSERT INTO kupione (produkt, Cena, nick,godzina,data_zakupu)
VALUES (:produkt,:Cena,:nick,:godzina,:data_zakupu)');
$stmt->bindParam(':produkt',$row['produkt'],PDO::PARAM_STR);
$stmt->bindParam(':Cena',$row['Cena'],PDO::PARAM_STR);
$stmt->bindParam(':nick',$_SESSION['logowanie'],PDO::PARAM_STR);
$stmt->bindParam(':godzina',$godzina);
$stmt->bindParam(':data_zakupu',$data_zakupu);
$stmt->execute();
$stmt->closeCursor();
//Admin sprzedaje produkt, zostaje przeniesiony do tabeli sprzedane
$stmt=$this->db->prepare('INSERT INTO sprzedane (produkt,Cena,data,godzina)
VALUES (:produkt,:Cena,:data,:godzina)');
$stmt->bindParam(':produkt',$row['produkt'],PDO::PARAM_STR);
$stmt->bindParam(':Cena',$row['Cena'],PDO::PARAM_STR);
$stmt->bindValue(':data',$data_zakupu);
$stmt->bindValue(':godzina',$godzina);
$stmt->execute();
$stmt->closeCursor();
//wysyła mail
$stmt = $this->db->prepare('SELECT email FROM uzytkownicy WHERE nick=:nick');
$stmt->bindParam(':nick',$_SESSION['logowanie'],PDO::PARAM_STR);
$stmt->execute();
foreach($stmt as $row)
{
$email = $row['email'];
}
$email = $email;
$subject = 'Zakup produktu';
$message = 'Dziekujemy za zakup produktów, w załączniku widnieje faktura. ';
mail($email, $subject, $message);
$stmt = $this->db->prepare('DELETE FROM Koszyk WHERE nick=:nick ');
$stmt->bindParam(':nick',$_SESSION['logowanie'],PDO::PARAM_STR);
$stmt->execute();
$stmt->closeCursor();
0
To co wrzuciłeś wyżej to jest jedna, duża funkcja? Wygląda jakby ktoś pisał to po weekendzie z poradnikami o PHP i PDO. Rozumiem napisać coś takiego dla siebie w domu, testując i ucząc się nowopoznanych funkcji w jakiejś mini apce-brudnopisie, ale rozbudowywać to w tej postaci na siłę to nie ma trochę sensu imo.
Nie odbierz mnie oczywiście źle bo absolutnie nie mam Cię zamiaru obrazić, po prostu zastanawiam się skąd to i po co bo nie wiem jak dalej się do tego odnieść :P
0
Pisząc to, ciągle uczę się php i pdo, Twoje przypuszczenia są jak najbardziej uzasadnione. Testowałem te rozwiązania i nie miałem zamiaru wstawiac tego jako efekt końcowy. Zastanawia mnie, w jaki sposób można to dobrze rozbudować, aby było to z sesnem.
0
Można zapytania rozdzielić na funkcję i dodawać je odpowiednio do funkcji głównej.
A może stworzyć nową klasę i metodą dziedziczenia wydobywać z niej poszczególne funkcje.
Jak będzie odpowiednio?
0
Widzę, że co chwilę zakładasz nowe wątki pytając w sumie o to samo i nie wiem gdzie Ci odpisać.
Nie do końca może dobrze się wyraziłem ponieważ nie tyle mi chodziło o samo pozbycie się funkcji dla pozbycia funkcji tylko, że część z nich myślę, że można się pozbyć jak nieco lepiej zoptymalizujesz bazę danych.
Np. nie rozumem idei dwóch tabel z podziałem na kupione i sprzedane (dla Sklepu to jedno licho przecież, towar poszedł, a hajs przyszedł) skoro i tak przy każdym sprzedanym produkcie dokonujesz zapisu w obu tabelach duplikując część danych.
Dodatkowo jeżeli jest tylko jeden Admin (nie rozróżniasz Adminów, czy też userów z uprawnieniami Admina w tabeli) i każdy produkt do niego przypisujesz to jaki sens w takim wypadku w ogóle ma taka tabela skoro wszystkie te same informacje możesz pobrać z tabeli KUPIONE?
Zapisujesz też zakupione towary po nicku użytkownika, a co jeżeli pewnego dnia postanowi zmienić sobie nick? Zgubisz jego wszystkie zamówienia jakich dokonał. Tak samo czy pilnujesz w bazie unikalność nicków? Co jak będzie kilku użytkowników z takim samym i będziesz chciał wyświetlić ich zamówienia, albo jak sprawdzisz później, któremu wysłać towar?
0
Założenia są takie że klient nie może zmieniać Swojego nicku, a autoryzacja sprawdza, czy w tabeli nie ma już nicku, który klient chce wprowadzić. Myślę że zmienię nick na pola imię i nazwisko. Co do tabeli sprzedane to faktycznie ją usunę i będe pobierał dane z tabeli kupione, gdyż produkty dodaję jako admin. Te niedopatrzenia biorą się z tego powodu, że początkowo miał być to portal aukcyjny, a nie typowy sklep.
0
Każdy dodany produkt do koszyka przez użytkownika zapisuje w sesji jako obiekt i nie inaczej. Jak dojdziesz np do checkotu to na zapisz json obiekt do bazy danych. Tabela np o nazwie checkout_logs. Dodaj tam jakiś id, user_id, step, data, date, comments etc. Co tam chcesz. Jeżeli masz kilka kroków w checkoucie to zapisz to jako np nazwa podstrony w kolumnie step. Jeżeli prowadzisz sklep to mega ważna rzecz. Musisz mieć tego typu logi albo i więcej. Dlaczego? Przyczyn jest cała masa. Chociażby dla statystyk. Np jak zwali się coś z płatnością i użytkownik zadzwoni do Ciebie to możesz sprawdzić logi i wiesz co się stało. Możesz pomoc mu w zapłata itd.