Desenvolvimento E-Commerce - Sessão ou Tabela

[Brenno Ferreira]

Galera bom dia,

Aí estou começando a remodelar um E-Commerce de vendas de ingressos On-Line.

Hoje tudo que é feito nesse e-commerce é gravado em sessão, ou seja se o "carrinho" do cliente fica tudo gravado na sessão. Estava pensando em passar isso para um tabela temporária até o login do cliente, onde iria transferir tudo para a tabela principal pedidos.
Qual a opinião de vocês? Deixar tudo na sessão é melhor? Gravar em uma tabela temporária e depois transferir para principal, consumindo mais conexões com o banco?

Atenciosamente,

Brenno Ferreira

[caferrari]

Depende....

Se você precisa que os itens do carrinho sejam persistentes (o usuário sai e depois, quando voltar, consiga recuperar o carrinho), grave no banco, caso contrário, não existe a menor necessidade de implementar isso e a melhor solução e manter na session mesmo.

[]'s

--
Você recebeu esta mensagem porque está inscrito na Lista "GOPHP" em Grupos do Google.
Para Postar: go...@googlegroups.com
Para Sair do Grupo: gophp-un...@googlegroups.com
Link: http://groups.google.com/group/gophp?hl=pt-BR
---
Você recebeu essa mensagem porque está inscrito no grupo "GOPHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para gophp+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Carlos André Ferrari
http://ferrari.eti.br
http://github.com/caferrari
http://meadiciona.com/caferrari
OpenPGP keys: 113D04FC

[Bruno Moraes]

Depende, o intuito é possibilitar o cliente continuar comprando mesmo depois de sair do sistema?

Vai salvar nessa tabela temporária só para não gravar na sessão?

Qual o objetivo com essa mudança?

Abs

Em 27 de novembro de 2014 11:52, Brenno Ferreira <brdesig...@gmail.com> escreveu:

--

Você recebeu esta mensagem porque está inscrito na Lista "GOPHP" em Grupos do Google.
Para Postar: go...@googlegroups.com
Para Sair do Grupo: gophp-un...@googlegroups.com
Link: http://groups.google.com/group/gophp?hl=pt-BR
---
Você recebeu essa mensagem porque está inscrito no grupo "GOPHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para gophp+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente;

Bruno Moraes

Development

0xx61 9197-2718

http://app2b.me

[Luís Henrique Faria]

Você pretende mudar este comportamento por alguma razão em especial?

Minha opinião é não mexer nisso sem uma boa razão.

--

[Sóstenes Gomes]

Olá Brenno, a minha opinião é melhor deixar na sessão. Também aconselho, conforme sua análise da aplicação, utilizar Memcached para otimizar a performance.

--

[Maykonn Welington Candido]

Só mais uma coisa, não use sessão do PHP. Se você já está refatorando o sistema então já faça isso da maneira correta permitindo que o sistema se torne escalável. E sessions não funcionam em um sistema distribuído. Pense comigo:

- Uma request de login chega no load balancer e então joga para o servidor A. O sessão ficará no servidor A (isso porque o PHP usa o filesystem para salvar os arquivos de sessão). Ok, cliente logado.

- Quando uma segunda request chegar no load balancer, digamos, fechar pedido, se o load balancer jogar para o server B do cluster, o que acontece? Cliente não está logado.

Uma solução é usar o redis ou memcache, ou um sistema de sessão em tabelas do banco de dados(também é não bom, mas não é de todo ruim), o indicado mesmo seria o redis ou memcache armazer a sessão dos clientes também, isso é bem fácil de se fazer.

Abraço!

Atenciosamente,

Maykonn Welington Candido

Em 27 de novembro de 2014 12:11, Maykonn Welington Candido <may...@outlook.com> escreveu:

Bom dia,

Mais conexões com o banco talvez não ocorra, a não ser que esses eventos de adicionar, retirar e editar quantidade de produtos do carrinho sejam por ajax, pois enquanto a aplicação cliente aguarda a resposta de um evento, por exemplo,  "Cart.remove(item)", poderia chamar um "Cart.setQty(2, item)". Ai você teria eventos assíncronos abrindo duas conexões com o database.

Caso contrário é uma conexão aberta por request de página certo?

Você tem alguma ideia do volume de escrita (transações com INSERT, UPDATE e mesmo DELETE) nessa tabela? Use uma tabela real não uma temporária, assim você pode futuramente adicionar novos relatórios do que está acontecendo no ecommerce próximo do tempo real, armazene esses dados, é bom, logo você consegue pensar em boas funcionalidades pra eles, mas uma é: Abandonei meu carrinho, depois de um certo tempo recebo um e-mail me alertando disso e dando algum desconto ou não por exemplo, deixando um CRON chamando um serviço (um url qualquer GET .php por exemplo) uma vez por hora que pega os carrinhos abandonados e realiza o processo.

Mas eu usaria Redis e um job extraindo aos poucos através de uma fila do Redis para o DB caso fosse ajax para os acessos não baterem diretamente no meu database, assim você pode fazer uma promoção e divulgar bem sem se preocupar muito com o mysql, apenas com o escalonamento do seu cluser Redis que é bem mais tranquilo  aguenta muuuuito mais impacto do que um mysql.

Abraço!

Atenciosamente,

Maykonn Welington Candido

Em 27 de novembro de 2014 11:52, Brenno Ferreira <brdesig...@gmail.com> escreveu:

--

[Maykonn Welington Candido]

Bom dia,

Mais conexões com o banco talvez não ocorra, a não ser que esses eventos de adicionar, retirar e editar quantidade de produtos do carrinho sejam por ajax, pois enquanto a aplicação cliente aguarda a resposta de um evento, por exemplo,  "Cart.remove(item)", poderia chamar um "Cart.setQty(2, item)". Ai você teria eventos assíncronos abrindo duas conexões com o database.

Caso contrário é uma conexão aberta por request de página certo?

Você tem alguma ideia do volume de escrita (transações com INSERT, UPDATE e mesmo DELETE) nessa tabela? Use uma tabela real não uma temporária, assim você pode futuramente adicionar novos relatórios do que está acontecendo no ecommerce próximo do tempo real, armazene esses dados, é bom, logo você consegue pensar em boas funcionalidades pra eles, mas uma é: Abandonei meu carrinho, depois de um certo tempo recebo um e-mail me alertando disso e dando algum desconto ou não por exemplo, deixando um CRON chamando um serviço (um url qualquer GET .php por exemplo) uma vez por hora que pega os carrinhos abandonados e realiza o processo.

Mas eu usaria Redis e um job extraindo aos poucos através de uma fila do Redis para o DB caso fosse ajax para os acessos não baterem diretamente no meu database, assim você pode fazer uma promoção e divulgar bem sem se preocupar muito com o mysql, apenas com o escalonamento do seu cluser Redis que é bem mais tranquilo  aguenta muuuuito mais impacto do que um mysql.

Abraço!

Atenciosamente,

Maykonn Welington Candido

Em 27 de novembro de 2014 11:52, Brenno Ferreira <brdesig...@gmail.com> escreveu:

--

[Sóstenes Gomes]

Bem observado por todos. Se você tem o objetivo de guardar a sessão para o cliente comprar no futuro, então faço como o pessoal disse, grave em uma tabela temporária para recuperar estes dados.

A observação do Maykon quanto ao Memcached ou Redis também é muito importante.

Pensando nos passos do seu checkout, persistir todos esses passos no banco fica muito mais trabalhoso e complexo na minha opinião.