Jump to content
ricardoM92

base de dados para um site de encomendas e carrinho de compras

Recommended Posts

ricardoM92

Ola amigos.

Estou a trabalhar num projecto da escola e necessito muito de uma base de dados para encomendas e de um carrinho de compras ...

se me poderem ajudar ficava muito grato :D

Comprimentos:

Ricardo.

Share this post


Link to post
Share on other sites
XsTeAl

preciso do euro milhoes.. quem da os numeros???

penso que ninguem te vai dar nada....

Share this post


Link to post
Share on other sites
scorch

@ricardoM92 Primeiro, retira o Urgente. Nínguem te vai ajudar mais rápido nem melhor por causa disso. Segundo, ou te explicas, mostras o que já tens feito e dizes qual é a tua dúvida em concreto ou o tópico será bloqueado por não estar em conformidade com as regras do fórum. :D


scorch_pp.png

PS: Não respondo a perguntas por mensagem que podem ser respondidas no fórum.

Share this post


Link to post
Share on other sites
ricardoM92

peço desculpa :S

até agora tenho o site ja mais ou menos desenvolvido ... registo e login feitos e aprefeiçoados ...

a base de dados tenho a tabela cliente, a onde tá os dados sobre os clientes inluindo o login (é a tabela a onde vao os dados do registo); tenho a tabela produtos e a tabela categoria que contem a categoria dos produtos ... ( hardware, software...)

as minhas duvidas são a tabela para relacionar o cliente com os produtos ... a tabela encomendas, mas quero fazer de maneira a que partir de um carrinho de encomendas os dados introduzidos no carrinho venham para essa tabela, mas não sei por onde começar a fazer a tabela e o carrinho ... até porque no meu curso aprender PHP é mesmo 0 :S o que sei foi práticamente adquirido sozinho :\

:s

isto é para a PAP e neste projecto infelizmente fiquei como professor auxiliar que não domina PHP nem HTML :S

Share this post


Link to post
Share on other sites
ruimcosta

Em quase tudo na vida escolar é assim mesmo...falam do tópico e depois temos de nos desenrascar.

Tabela clientes:

id

cliente

Tabela artigo

id

artigo

preco

Tabela ENCOMENDA_CABECALHO

id

id_cliente

total_encomenda

desconto_pp

data

Tabela ENCOMENDA_LINHAS

id

id_encomenda_cabecalho

id_artigo

preco // Para ficar registado o preco, de outra forma mudas o preco na tabela artigos e perdes o historico

qt

desconto

iva

total

data

De uma forma simplória tens aqui uma base para inciar.


Abraços e beijinhos,Rui Costa

Share this post


Link to post
Share on other sites
ricardoM92

obrigado pela ajuda ... agora é programar...

posso associar a tabela ecomenda cabeçalho ao carrinho de compras ? ?

Share this post


Link to post
Share on other sites
ruimcosta

podes chamar-lhe o que quiseres...carrinho, encomendas...etc...

O que eu te dei era para servir de "carrinho".


Abraços e beijinhos,Rui Costa

Share this post


Link to post
Share on other sites
rjcarneiro

O conceito de carrinho não é o conceito de encomenda.

Acho que na tabela ENCOMENDA_CABECALHO falta o campo NUMERO_ENCOMENDA ou entao o ID serve como nº encomenda. (se for inteiro. Disse isto como uso GUID tenho que ter sempre um campo NUM_ENC)

Agora o conceito de carrinho é um cliente "anonimo" ir ao site, adicionar cenas ao carrinho e no fim fazer checkout, fazer login ou registar e validar a encomenda. E apartir dai é que é inserido os valores nessas 2 tabelas.

O mais eficaz de carrinho de compras é com cookies. O utilizador vai inserir os produtos com as quantidades, que é registado num cookie. E tudo depois é processado atraves desse cookie.

Vantagens:

O cliente pode estar anonimo e se sair do site e voltar no dia seguinte, as compras dele continuam la (se nao eliminou os cookies)

Desvantagens:

Mais complexo de programar.

Share this post


Link to post
Share on other sites
ruimcosta

Foi somente uma ideia base, no entanto poderia da mesma forma, anonimamente ou via registo/login utilizar essa tabela com mais alguns campos para processar toda a encomenda e depois finalizar ou nao.

Se o cliente não tiver efectuado o login, posso guardar a session_id() e guardar no cookie para se voltar amanha mostrar de imediato informações de que tem uma encomenda pendente.

E guardando num campo (ex.: Estado_encomenda) o 1, para pendente e o 2 para finalizado, desta forma enquanto não finalizasse a encomenda a mesma encontrar-se-ia no estado um. Havendo finalização, passaria para o acto do pagamento e após confirmação do recebimento, passar o estado_encomenda a 2.

São apenas ideias. A forma como se desenvolve o processo de compra é um pouco relativa. Depende do que se pretende implementar. Somente um ponto de vista.

Em relação à desvantagem que apontas, qualquer processo de compra, mais básico ou "menos" básico torna-se complexo de programar se quisermos tudo bem validado, bem seguro e bem fácil para o utilizador manusear.

São pontos de vista.


Abraços e beijinhos,Rui Costa

Share this post


Link to post
Share on other sites
rjcarneiro

Sim, isso é uma possivel solução mas não acho muito eficaz.

Estás a desperdiçar recursos e tamanho do SGBD sem necessidade. Apenas registava encomenda se o cliente validasse mesmo a encomenda. É um metodo eficaz.

O facto de usar cookies, é tudo client-side o processamento, deixando o server mais limpo e mais leve.

Não quer dizer que a tua ideia não funcione. Funciona. Mas o que estou a dizer é mesmo a nível de eficácia.

Algo bem feito seria da minha maneira.

Algo para funcionar e já está, pode ser feito de diversas maneiras.

Share this post


Link to post
Share on other sites
rjcarneiro

A nivel de complexidade, se usares cookies, possivelmente terás que usar expressoes regulares para tirares de lá os n artigos que o cliente "encomendou"

Um cookie só leva 1 linha de texto, ou seja terias de agrupar algo do genero:

session_id()|article_id()/quantidade|article_id2/quantidade

onde  '|' separava o session_id e as n linhas da encomenda

e / separava o artigo da quantidade.

Ou seja, ia ser bem mais complexo de programar, do que simples inserts em base de dados.

Share this post


Link to post
Share on other sites
ruimcosta

Quando falei em cookies, referia-me apenas a armazenar um identificador do cliente que após login seria substituido pelo seu id de utilizador.

Todo o armazenamento é feito em base de dados.

Agora estava a ler melhor a tua resposta e OU eu percebi mal ou contradizes-te:

Estás a desperdiçar recursos e tamanho do SGBD sem necessidade. Apenas registava encomenda se o cliente validasse mesmo a encomenda. É um metodo eficaz.

O facto de usar cookies, é tudo client-side o processamento, deixando o server mais limpo e mais leve.

A nivel de complexidade, se usares cookies, possivelmente terás que usar expressoes regulares para tirares de lá os n artigos que o cliente "encomendou"

Um cookie só leva 1 linha de texto, ou seja terias de agrupar algo do genero:

session_id()|article_id()/quantidade|article_id2/quantidade

onde  '|' separava o session_id e as n linhas da encomenda

e / separava o artigo da quantidade.

Ou seja, ia ser bem mais complexo de programar, do que simples inserts em base de dados.

Mas afinal segundo o que disseste em 2 posts seguidos, num dizes que é melhor utilizar cookies e depois dizes que é muito mais complexo?

Não entendi....


Abraços e beijinhos,Rui Costa

Share this post


Link to post
Share on other sites
ricardoM92

muito obrigado :thumbsup:

abas as duas ideias me parecem muito boas ... ;)

seja com cookies ou com o session ...

agora tenho de ver para mim qual a mais facil ...

é que não pesco muito disto :\

prefiro C# embora php seja uma lingua derivada do C

xD

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.