Banco de Dados para Ecommerce

[Sylvio Leonel 1]

fala galera

 

eu estou fazendo um sistema de ecommerce, e minha intenção é que ele tenha alguns diferenciais tipo comentários e notas para os produtos, descontos e ofertas, vídeos sobre os produtos, além de uma boa área de administração.

 

acabei de modelar o banco de dados e gostaria da opinião de vcs.

 

 

qualquer opinião, sugestão e crítica é bem vinda.

[Sylvio Leonel 1]

só algumas informação que não tem na imagem...

 

para todas as tabelas que tem "status" é se aquele registro esta ativo ou inativo (0 ou 1 respectivamente), por isso TINYINT(1)...

na tabela OFERTAS, o campo tipo CHAR(1) se refere 'Q' OFERTAS_POR_QUANTIDADE, e 'D' OFERTAS_POR_DATA

[h4v3st 1]

Sylvio, gostei muito do seu modelo. Está completo! :)

[VascoDaGama 2]

A tabela "países" e "estados" são dados estáticos. Pode-se usar arquivos texto, xml ou arrays.

A tabela cidade é util no banco de dados e mais pratico devido volume de dados.

 

Outra desvantagem nessa estrutura é que cidade fica vinculado a estado que por sua vez é vinculado a países.

 

Há muitos países que não são dividos em estados, possuem apenas cidades ou apenas regiões.

Outros países não possuem estados e sim, províncias divididas por regiões.

 

Enfim, o que quero dizer é que do ponto de vista "internationalization", não é recomendável esse tipo de estrutura.

 

Estou comentando isso porque presumo que a tabela países tenha a finalidade de internacionalização.

 

Na tabela de endereços, o CEP está varchar(45).

CEP ou "postal code" é sempre numérico por convenção interncional.

Não conheço nenhum postal code acima de 8 dígitos. Por isso, você pode definir como int(9) ou (10).

Na tabela clientes, crie um campo "Surname" (sobrenome).

CPF é deveria ficar em outra tabela separada, pois nem todo mundo tem CPF, principalmente pessoas de outros países.

 

Informação sobre telefone e celular pode ficar numa tabela separada, assim como está separado para endereço, pois um mesmo usuário pode ter mais de um endereço ou mais de um celular ou telefone fixo.

 

 

Continuando o assunto "internationalization", adote nomenclatura em inglês, pois é um idioma universal.

suponha que um dia você mude emprego ou tenha que treinar outra pessoa, por exemplo, um paraguaio ou um americano ou um alemão para manter o sistema. O coitado vai ter dificuldade com português.. Imagine a situação inversa, você pegando um sistema desenvolvido por um indiano, e o cara usou nomenclaturas em hindu..

 

No restante, a estrutura está muito bem montada.

 

Só dou mais uma dica, referente a performance.

 

Na tabela de produtos existirão produtos ativados e outros desativados.

Desativados são produtos que não serão mostrados aos clientes, não é ?

 

suponha que a tabela de produtos tenha 20 mil items, dos quais 15 mil estejam desativados

 

o website fica mais pesado para fazer filtragens de busca nessa tabela.

está certo que 20 mil items é pouca coisa, mas pense num website com volume de 12 mil visitas unicas por dia, o que é pouco, pois o normal para um ecommerce lucrativo e movimentado é algo em torno de 20 mil unicos por dia.

 

isso pesa muto o sistema.

por isso, faça planejamento de estrutura de cache.

 

exemmplo, crie uma tabela chamada "ItemsPublic", que seria utilizada para armazenar todos o produtos ativados.

 

o sistema do website trabalharia com essa tabela mais leve, e para buscar detalhes pode-se utilizar a tabela original, pois o uso não será tão intenso.

 

A tabela de pedidos também ficará enorme em pouco tempo

Por isso, sempre esvazie-a e guarde os dados originais em outra tabela para consulta posterior. seria uma tabela de historico de pedidos, um log, algo do tipo. Jamais apague nenhuma movimentação, pois sempre precisará desses dados algum dia.

Guarde também um log de modificações de cadastro. O endereço por exemplo é muito comum o cliente confirmar o pedido com endereço errado.

Tem cliente que muda de endereço e não altera nos cadastros online, aí faz o pedido e depois vem reclamar que nao recebeu. Se você tiver o log de historico de alterações de cadastro poderá provar que o cliente que fez cagada.

[giesta 29]

CEP ou "postal code" é sempre numérico por convenção interncional.
Não conheço nenhum postal code acima de 8 dígitos. Por isso, você pode definir como int(9) ou (10).

Não vivemos no mesmo planeta entao :P

 

http://en.wikipedia.org/wiki/List_of_postal_codes

[Sylvio Leonel 1]

A tabela "países" e "estados" são dados estáticos. Pode-se usar arquivos texto, xml ou arrays.

A tabela cidade é util no banco de dados e mais pratico devido volume de dados.

 

Outra desvantagem nessa estrutura é que cidade fica vinculado a estado que por sua vez é vinculado a países.

 

Há muitos países que não são dividos em estados, possuem apenas cidades ou apenas regiões.

Outros países não possuem estados e sim, províncias divididas por regiões.

 

Enfim, o que quero dizer é que do ponto de vista "internationalization", não é recomendável esse tipo de estrutura.

 

Estou comentando isso porque presumo que a tabela países tenha a finalidade de internacionalização.

 

Na tabela de endereços, o CEP está varchar(45).

CEP ou "postal code" é sempre numérico por convenção interncional.

Não conheço nenhum postal code acima de 8 dígitos. Por isso, você pode definir como int(9) ou (10).

Na tabela clientes, crie um campo "Surname" (sobrenome).

CPF é deveria ficar em outra tabela separada, pois nem todo mundo tem CPF, principalmente pessoas de outros países.

 

Informação sobre telefone e celular pode ficar numa tabela separada, assim como está separado para endereço, pois um mesmo usuário pode ter mais de um endereço ou mais de um celular ou telefone fixo.

 

 

Continuando o assunto "internationalization", adote nomenclatura em inglês, pois é um idioma universal.

suponha que um dia você mude emprego ou tenha que treinar outra pessoa, por exemplo, um paraguaio ou um americano ou um alemão para manter o sistema. O coitado vai ter dificuldade com português.. Imagine a situação inversa, você pegando um sistema desenvolvido por um indiano, e o cara usou nomenclaturas em hindu..

 

No restante, a estrutura está muito bem montada.

 

Só dou mais uma dica, referente a performance.

 

Na tabela de produtos existirão produtos ativados e outros desativados.

Desativados são produtos que não serão mostrados aos clientes, não é ?

 

suponha que a tabela de produtos tenha 20 mil items, dos quais 15 mil estejam desativados

 

o website fica mais pesado para fazer filtragens de busca nessa tabela.

está certo que 20 mil items é pouca coisa, mas pense num website com volume de 12 mil visitas unicas por dia, o que é pouco, pois o normal para um ecommerce lucrativo e movimentado é algo em torno de 20 mil unicos por dia.

 

isso pesa muto o sistema.

por isso, faça planejamento de estrutura de cache.

 

exemmplo, crie uma tabela chamada "ItemsPublic", que seria utilizada para armazenar todos o produtos ativados.

 

o sistema do website trabalharia com essa tabela mais leve, e para buscar detalhes pode-se utilizar a tabela original, pois o uso não será tão intenso.

 

A tabela de pedidos também ficará enorme em pouco tempo

Por isso, sempre esvazie-a e guarde os dados originais em outra tabela para consulta posterior. seria uma tabela de historico de pedidos, um log, algo do tipo. Jamais apague nenhuma movimentação, pois sempre precisará desses dados algum dia.

Guarde também um log de modificações de cadastro. O endereço por exemplo é muito comum o cliente confirmar o pedido com endereço errado.

Tem cliente que muda de endereço e não altera nos cadastros online, aí faz o pedido e depois vem reclamar que nao recebeu. Se você tiver o log de historico de alterações de cadastro poderá provar que o cliente que fez cagada.

 

 

fala cara

me amarrei nas tuas dicas.

 

eu ja tinha ideia mesmo em tirar os paises do banco de dados e utilizar em XML e o usuario administrador do sistema escolhe quais ele quer disponibilizar, estados eu acho que também seria uma boa ideia fazer isso...

quando a esse lance de cidades confesso que não sabia..., vou dar uma pesquisada sobre isso pra chegar a uma boa solução.

Realmente não é necessário que o campo CEP tenha tamanho 45..., acho que tem alguns paises que utilizam letras tb..., vou dar uma pesquisada nisso tb.

 

Eu gostei dessa ideia de usar um campo para nome e outro para o nome completo..., pode ser útil em uma tela de apresentação.

 

Agora..., eu realmente não entendi esse lance.

CPF é deveria ficar em outra tabela separada, pois nem todo mundo tem CPF, principalmente pessoas de outros países.

acho que o campo CPF é indispensavel para qualquer transação eletronica. Em outros paises talvez não exista CPF como o nosso..., mas tem um documento equivalente.

Mais uma coisa que vou pesquisar!

 

Tb gostei da sua ideia de criar tabelas somente com os dados ativos!

Talvez criando VIEWS esse problema seja resolvido.

Oq você acha? VIEWS são mais leves que tabelas e suprem esse problema.

me da sua opinião...

 

Quanto a esses campos de status para ativar e desativar registros é pelo seguinte...:

eu não posso deletar nenhum produto do banco de dados! ( a não ser que não tenha nenhum pedido dele )

 

do mesmo jeito também não posso deletar nenhum pedido, endereço e varios outros...

 

quanto ao endereço..., aquele campo tipo_endereco identifica se o endereço é residencial ou de entrega...

então, a cada compra que o usuario for realizar o sistema vai perguntar ao cliente se ele quer que a compra seja entrege no seu endereço residencial ou em outro, caso ele escolha outro ele vai cadastrar mais um endereço...

 

vlw pela opinião

[giesta 29]

pq tirar os paises do banco e colocar em XML?

[Sylvio Leonel 1]

pq tirar os paises do banco e colocar em XML?

 

sim, ja que é uma informação "fixa" ( tudo bem que novos paises podem ser criados... ).

você acha uma má ideia?

[Prog 183]

Modelagem de dados é um lance muito "particular", que vai de encontro basicamente ao negócio que cada sistema precisa como resposta (velocidade, integridade, segurança, controle, localização, internacionalização, ...). É necessáriio colocar cada um desses itens numa balança comparando com o projeto que será implementado, se todos os itens forem de extrema importância, aí você vai ter um modelo de dados extremamente complexo e conforme cada item vai tornando-se menos importante, você vai "relaxando" aqui ou ali para atingir este determinado objetivo.

 

No caso de uma solução ECommerce, bem... as primeiras perguntas que faço pra ti:

- Este sistema esta sendo desenvolvido para UM cliente específico ou vai ser para atender qualquer um?

- Caso seja para um cliemte específico, a abrangência de atuação do mesmo é apenas nacional ou internacional também?

 

Algumas tabelas com informações estáticas podem ser opcionais no modelo. Você pode mantê-las para criar regras de integridade, no mesmo módulo ou em módulos distintos (ex.: módulo financeiro, módulo logístico, etc), mas se este não for o caso... Manter este controle na aplicação não afetaria o comportamento dos seus dados. Sacou?

[Sylvio Leonel 1]

fala Prog

saquei sim cara!

 

quanto a pergunta que você me fez, esse ecommerce é voltado para um cliente especifico que tem seu mercado voltado para o Brasil.

eu fiz esse esquema de paises pensando futuramente, porq pode ser que o cliente queira..., e ja tendo isso planejado facilitaria dimais.

e além disso eu posso usar esse mesmo sistema para outros clientes, apenas fazendo algumas modificações.

 

vlw

[giesta 29]

o problema do xml eh fazer os relatorios depois

[VascoDaGama 2]

foi mal, o lance do cep, digitei int() quis digitar char() mas não conseguir editar o post.. não dá pra editar os posts

 

mas nao gostei do comentario irônico... tenha um pouco de profissionalismo antes de sair criticando a torta e a direita..

[VascoDaGama 2]

Oq você acha? VIEWS são mais leves que tabelas e suprem esse problema.

me da sua opinião...

vai dar "na mesma"

 

views só simplificam uma query dentro dos comandos da linguagem de programação que faz a conexção com o banco.

o banco gera cache e otimização específica para views, mas mesmo assim, a performance é melhor com dados já enxutos e filtrados.

 

mas nao quer dizer que views sejam inuteis.. são muito uteis para outras finalidades.

 

 

quanto aos paises e estados ou províncias, regiões, etc.. pode fazer em aquivos texto mesmo.. em xml ou mesmo dentro do php em arrays.

 

eu prefiro dessa forma porque sempre que precisar listar os países numa pagina de cadastro por exemplo, não precisa fazer conexão ao banco de dados para essa finalidade.. Esse é motivo principal.

 

Outro motivo é o idioma.

algum dia que precisar de um sistema que utilize 2 ou mais idiomas fica mais simples e prático criar esses arquivos texto em outros idiomas.

 

 

quanto a relatórios.. tb não vejo problema.

quando for imprimir algo, a linguagem de programação verifica o código do país ou estado, e busca no arquivo texto ou vetor..

 

 

 

e além disso eu posso usar esse mesmo sistema para outros clientes, apenas fazendo algumas modificações.

então... procure saber sobre internacionalização

 

 

estou aconselhando porque ao ver sua estrutura eu lembrei de mim mesmo alguns anos atrás quando estava iniciando.

 

muitos sistemas que fiz no inicio da carreira, hoje são praticamente inúteis porque nao pensava de modo global.

hoje faço tudo reaproveitando módulos de um framework

 

se um cliente quer um software para controle financeiro, eu posso usar o mesmo framework que utilizo para outro cliente que pediu um ecommerce, e por aí vai..

 

frameworks são vários como .NET, cakePHP, zend, codeigniter, etc..

[Sylvio Leonel 1]

foi mal, o lance do cep, digitei int() quis digitar char() mas não conseguir editar o post.. não dá pra editar os posts

 

mas nao gostei do comentario irônico... tenha um pouco de profissionalismo antes de sair criticando a torta e a direita..

 

foi pra mim isso?

não fui irônico em momento algum!

mas tudo beim...

[VascoDaGama 2]

não..

foi para o moderador

 

Não vivemos no mesmo planeta entao

 

http://en.wikipedia....of_postal_codes

acho que o cara como moderador é quem deveria ter uma postura mais profissional..

 

mas nao vou ficar chateado com isso.. só comentei abertamente que nao achei legal..

[giesta 29]

lol