Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Paulo de Tarso F. M.

Modelando menu com até 3 níveis...

Recommended Posts

Pessoal!

 

Seguinte, tenho a seguinte situação: uma loja de autopeças terá seus produtos divididos em categorias e subcategorias. Ok. A minha dúvida é como montar as tabelas de categorias e subcategorias adequadamente? Seria simples se tivéssemos apenas categorias e subcategorias, mas não é o caso.

 

Todas as categorias possuem subcategorias. Até aqui tudo bem, temos uma tabela categorias, com o id e a descrição. O problema vem agora: uma subcategoria pode ter ou não outras subcategorias, mas essas subcategorias que possuem subcategorias na verdade não são uma subcategoria, mas sim apenas um "agregador" de subcategorias...

 

Imaginando um menu de um site, teríamos algo mais ou menos assim:

 

modelo.png

 

Observem que um produto poderá estar em Motor > Radiadores quanto em Motor > Correias > Correia "Poly-V". Como eu devo montar as tabelas de categorias e subcategorias, fazendo um relacionamento no qual um produto deve pertencer a uma categoria e uma única subcategoria, e esta pode ser uma subcategoria exibida em 2º nível ("Radiadores", por exemplo) ou 3º nível ("Correias dentadas", por exemplo).

 

Ou seja, nunca teremos um produto em Correias, mas sim em uma de suas subcategorias, pois Correias é uma espécie de "agregador" de subcategorias, como falei anteriormente.

 

 

O que vocês sugerem? :mellow:

Compartilhar este post


Link para o post
Compartilhar em outros sites

Eu utilizaria recursividade nas tabelas, como sugeri neste artigo (ali uso PHP e MySQL, mas a lógica serve para qualquer banco relacional).

 

Carlos Eduardo

Compartilhar este post


Link para o post
Compartilhar em outros sites

Meu caro Matias, li a matéria e entendi "por cima" como funciona o esquema, tanto em relação à sua função quanto à proposta do João... Mas fiquei com dúvida no seguinte:

 

Tudo bem, as categorias e subcategorias serão utilizadas para montar um menu, mas independentemente, acredito que as entidades categorias e subcategorias não podem deixar de existir... Elas classificam os produtos, e a forma de exibição dessas informações não deveriam interferir na questão do banco, não acha?

 

A questão é: teria como as tabelas existirem separadamente e, para a utilização em um menu, existiria essa tabela de menu infinito? :mellow: Mesmo porque, seguindo o modelo que coloquei no primeiro post, teoricamente não existe uma subcategoria chamada Correias, ela existe apenas para agrupar outras subcategorias, ou seja, nenhum produto irá pertencer à subcategoria Correias porque ela simplesmente não existe!

 

Conseguiu captar onde pretendo chegar? Gostaria de encontrar uma solução que represente bem fielmente a estrutura das informações referentes às categorias/subcategorias de produtos e os próprios produtos, mas que, visualmente falando, pudesse ser apresentada da maneira informada anteriormente...

 

 

:joia:

Compartilhar este post


Link para o post
Compartilhar em outros sites

Então, Paulo. Acredito que esta sua situação das entidades deva ser resolvida dentro da aplicação, no ORM, e não na modelagem do banco de dados.

 

Veja, quando um registro tem menuIdPai como NULL, ela é uma categoria principal. Quando menuIdPai é diferente de NULL, ela é sub-categoria, ou seja, estará ligada a outro menu, ou seja, tem um pai.

 

Não vejo como poderia ser feito da forma que você quer fazer sem duplicar informações ou criar 3 tabelas (assumindo que o máximo sejam 3 opções de menu).

 

Carlos Eduardo

Compartilhar este post


Link para o post
Compartilhar em outros sites

Então...

 

Concorda comigo que essa necessidade de exibição em três níveis de menu é apenas visual? Vamos imaginar a utilização dos dados dos produtos em outro local, de uma outra forma. De repente, nesse outro local, os "agregadores" de subcategorias (Correias no exemplo) não existirão... Mas os dados do produto sim, como a Categoria e Subcategoria à qual ele pertence. E só.

 

Não que meu banco de dados não terá uma tabela para armazenar essas informações de principal, 2º e 3º nível, não é isso. Eu gostaria apenas de enxergar uma forma, então, de haver três tabelas: uma que armazene os dados das categorias, outra que armazene os dados da subcategoria e outra que gerencie a exibição do menu no site, sendo que essa terceira teria ligação com os dados da primeira e segunda tabela... :huh:

 

Dessa forma eu teria uma separação entre os dados dos produtos e os elementos que são utilizados somente pela aplicação, no caso, essa terceira tabela, que poderia se chamar menu perfeitamente, ou menu_site, enfim...

 

É possível estruturar o banco dessa forma?

Compartilhar este post


Link para o post
Compartilhar em outros sites
É possível estruturar o banco dessa forma?

Possível até é, mas eu acho errado. Ainda acho que o melhor é você manter como sugerido ali.

 

Concorda comigo que essa necessidade de exibição em três níveis de menu é apenas visual?

Não necessariamente. Se você precisar, por exemplo, fazer um breadcrumb, você precisa saber todo o caminho percorrido, desde a primeira até a última categoria.

 

Mas os dados do produto sim, como a Categoria e Subcategoria à qual ele pertence

Na verdade o produto sempre vai estar ligado à uma Categoria. Se esta categoria estará ligada a outra, não cabe ao produto saber isto, pelo menos na minha opinião.

 

Vamos associar com o fórum, por exemplo. Você tem um fórum, que tem seus sub-fóruns. Cada um destes sub-fóruns pode ter N sub-fóruns e assim sucessivamente. Veja que a modelagem é a mesma. Se você precisar de mais um nível, da forma que você está imaginando, você precisará modificar o banco, e isto normalmente não é muito bom.

 

Qual a restrição em trabalhar da forma sugerida?

 

Carlos Eduardo

Compartilhar este post


Link para o post
Compartilhar em outros sites

Qual a restrição em trabalhar da forma sugerida?

Nenhuma! :P

 

Isso é apenas para discutir, para eu poder entender, saber outras opiniões e assim aprender também... Bom, acredito que agora já tenho argumentos suficientes para adotar a solução proposta (afinal de contas, era esse o propósito do tópico, né? B) )

 

Vou seguir as sugestões e, caso eu tenha mais alguma dúvida, volto a escrever aqui!

 

 

Muito obrigado Matias!

Compartilhar este post


Link para o post
Compartilhar em outros sites

Qual a restrição em trabalhar da forma sugerida?

Nenhuma! :P

 

Isso é apenas para discutir, para eu poder entender, saber outras opiniões e assim aprender também...

 

Com certeza... E só de te responder eu tive que pensar um bom tanto, para poder ter certeza que era a melhor opção.

 

Se alguém tiver um pensamento diferente, pode postar. A discussão é sempre importante.

 

Carlos Eduardo

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.