OT: Categorias e SubCategorias infinitas

[Luis Henrique Machado Jr.]

Senhores,

Estava eu pensando qual seria a maneira mais correta de fazer categorias e
subcategorias infinitas, fui até o canal do #mysql na freenode, e me
falaram:

"SQL was not made for hierarchical storage" :(

Eu preciso fazer um sistema para uma loja de produtos.
As categorias podem ser cosias do tipo:

Brinquedos -> importados -> carrinhos
Roupas -> Masculinas -> blusas -> mangas curtas
Sapatos -> Masculinos -> Chinelos -> Importados -> Sem cheiro -> vermelhos
(:P)


Cada uma dessas categorias pode ter produtos (fotos) dentro e não somente a
última

Eu pensei em fazer assim, com uma tabela só:

| id | idpai | nome
------------------
| 1  | 1 | Roupas
| 2  | 1 | Masculinas
| 3  | 2 | Blusas


E assim vai..

Alguem tem uma idéia melhor?


Obrigado!

   

[Ricardo]

não, eu faria o mesmo, é simples....

2008/4/11 Luis Henrique Machado Jr. <Henr...@termolar.com.br>:

--
Ricardo L. Silveira
http://srsilveira.com/blog

[Er Galvão Abbott]

"SQL was not made for hierarchical storage"

Olha, eu não sou expert em Banco de Dados, mas à não ser que eu esteja sendo absolutamente ignorante (se eu estiver por favor alguém me dê um tapa no ouvido hehe) essa frase que te disseram é uma grande bobagem.

Eu já trabalhei com níveis/subníveis recursivos/"infinitos" com PostgreSQL sem o menor problema, fazendo exatamente como você fez: um "auto-relacionamento" (aliás uma coisa legal seria voltar lá no #mysql e perguntar "If SQL was not made for hierarchical storage why self-relationships exist in the first place?").

O auto-relacionamento pra quem não conhece é um troço muito interessante: Você "migra" a chave primária de uma tabela pra ela mesma.

Abraços,

www.phprs.com.br   Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao MSN: erga...@hotmail.com Visite meu blog sobre desenvolvimento web: http://blog.galvao.eti.br/

[Jony dos Santos Kostetzer]

Esse modelo aqui é consolidado para trabalhar com hierarquias:

http://dev.mysql.com/tech-resources/articles/hierarchical-data.html

Deve ter algum plugin isolado que te ajude a trabalhar com nested sets. No framework Symfony tem um behavior chamado ActsAsNestedSet (tem leves bugs ao trabahar com escopos diferentes, justamente q nao foram cobertos nos testes unitários, mas funciona bem, usei em larga escala).

Resta procurar algum componente isolado que implemente esse modelo, ou fazer "na mão" mesmo :)
Ou usar o Symfony, que é uma boa pedida..
CakePHP não sei se tem plugin semelhante.

Abraço!

Jony dos Santos Kostetzer
http://jonysk.net

Er Galvão Abbott escreveu:

[Fernando Norte]

Olá Galvão,

Eu também posso colocar a minha orelha a mostra, que também fiquei com dúvida, mas se eu tiver certo vai o meu tapa na sua... (slap... rs)

Se não me engano, "hierarchial storage" se refere a forma de armazenamento do SGDB. E realmente é uma forma diferenciada e não mais usual, pois o SQL dominante no 'mercado', se não me engano, usa armazenamento indexado ("indexed storage"), ao invés da antiga forma hierarquica. (não me peça maiores detalhes por enquanto, mas assim que eu reaver meu livro de modelagem de dados eu confirmo isso). Sistemas de Banco de Dados como o Dbase II Plus que usavam esse tipo de organização, tanto que os sistemas na mesma linguagem era comum criar funções para reindexar as bases de dados que era demorado e portanto manual.

Acho que houve um problema de comunicação com a língua no irc, pois ele perguntou sobre "hierarchial STORAGE" ao invés de "DATA". ;)

Abraços,

2008/4/11 Er Galvão Abbott <gal...@phprs.com.br>:

"SQL was not made for hierarchical storage"

Olha, eu não sou expert em Banco de Dados, mas à não ser que eu esteja sendo absolutamente ignorante (se eu estiver por favor alguém me dê um tapa no ouvido hehe) essa frase que te disseram é uma grande bobagem.

--
Fernando G. Norte
BHte - MG
cel: +55 31 9119 8814
-------------------------
MSN e Gtalk # fno...@gmail.com

[Er Galvão Abbott]

On Sat, 2008-04-12 at 21:48 -0300, Fernando Norte wrote:

Olá Galvão,

Olá, Fernando.

Eu também posso colocar a minha orelha a mostra, que também fiquei com dúvida, mas se eu tiver certo vai o meu tapa na sua... (slap... rs)

Heh, agora fiquei de orelha quente.

Se não me engano, "hierarchial storage" se refere a forma de armazenamento do SGDB. E realmente é uma forma diferenciada e não mais usual, pois o SQL dominante no 'mercado', se não me engano, usa armazenamento indexado ("indexed storage"), ao invés da antiga forma hierarquica.

Até aí eu entendo e concordo, mas isso não significa que não seja possível armazenar dados hierárquicos. Essa resposta dada à ele foi muito "insegura". Ok, se a gente for analisar o bit do bit do disco talvez pudéssemos dizer que o SGBD não é o mais indicado para armazenar esse tipo de estrutura, mas honestamente desconheço qualquer alternativa viável. Por exemplo, hierarquia me remete ao DOM, que por sua vez me remete ao XML. Hierarquia parece um prato cheio pro XML justamente porque ele próprio é uma linguagem hierárquica, mas eu me sinto mais seguro com um SGBD.

Eu sou da opinião que um SGBD bem projetado e configurado tem robustez suficiente pra armazenar MUITA coisa (no projeto que mencionei anteriormente armazenávamos milhões de registros hierarquicamente e ainda fazíamos relacionamento com outras tabelas), por isso torço o nariz quando alguém diz algo como "Não faça, SGBDs não foram feitos pra isso" ou "o SGBD não vai suportar isso".

(não me peça maiores detalhes por enquanto, mas assim que eu reaver meu livro de modelagem de dados eu confirmo isso). Sistemas de Banco de Dados como o Dbase II Plus que usavam esse tipo de organização, tanto que os sistemas na mesma linguagem era comum criar funções para reindexar as bases de dados que era demorado e portanto manual.

Acho que houve um problema de comunicação com a língua no irc, pois ele perguntou sobre "hierarchial STORAGE" ao invés de "DATA". ;)

Não havia me dado conta disso. Você provavelmente está certo.

Abraços,

www.phprs.com.br   Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao MSN: erga...@hotmail.com Visite meu blog sobre desenvolvimento web: http://blog.galvao.eti.br/

Abraços,

[Claudio T. Cardozo]

Oi pessoal, boa tarde,

 

Vejam se conseguem me ajudar: Tenho um software que gerencia um calendário, com datas e descrições, muito parecido com o que o MS Outlook faz, porém, é feito em PHP e possui integração com outros módulos deste sistema.

Já procurei em diversos lugares e não consegui encontrar, um Plugin ou algo do gênero que consiga sincronizar o calendário do Outlook com uma fonte de dados externa.

Bom, qual é a minha idéia: Publicar o calendário via XML ou RSS (tanto faz p/ mim) de forma que este plugin consiga ser executado pelo meu usuário final, e conecte-se à esta fonte de dados e sincronize o Outlook local com os dados que ali existem.

Porque preciso disso: Uma parte dos “atores” do sistema utiliza por várias vezes notebooks, e já estão muito acostumados com o uso do Outlook. Estes “atores” utilizariam apenas o recurso de agenda, e ao invés de se conectar diretamente ao sistema para verificar suas agendas, eles poderiam realizar uma única conexão com a internet, sincronizar a agenda através deste PLUGIN e desconectar. Continuar a trabalhar offline (viajando, durante a semana) e ao final de um período, realizar o sincronismo novamente, pois outras pessoas já teriam adicionado mais compromissos para eles, para os próximos dias.

 

Bom, se alguém souber de algo do gênero, irá me ajudar bastante, ok?

Abraços,

 

Cláudio Cardozp.

cla...@constat.com.br

 

[Walker de Alencar]

Olá,

Acabei de ver a discussão. então. vou dar uma palestra dia 26/04 em
Brasília-DF, no Flisol-DF, justamente sobre esse assunto.

Auto-Relacionamento Hierarquico com MySQL e PostgreSQL. Mais detalhes:
http://www.flisoldf.blog.br/?page_id=9

Ainda nao publiquei o Material em lugar algum, apenas compartilhei com
o Alexandre Altair de Melo (Autor do livro: PHP Profissional).

Indo aos fatos...

O Oracle tem suporte nativo.
PostgreSQL e MySQL, não possui nada para gerir isso, mas há como criar
metodologias que facilitem essa implementação.

A Grande questão é que não tem como vc ordenar a listagem de forma
hierárquica na consulta SQL apenas com esses campos: id, idroot, nome.

Vc precisaria de +1 campo para gerenciar isso, onde vc pode concatenar
a hierarquia, sem esquecer de usar um separador.

Esse campo deve ser atualizado a cada inserção/update/deleção de
categorias, e em caso de deleção fazer uma checagem rigorosa quanto a
dependentes. Para nao ter categoria orfã.

Ainda estou concluindo o material para divulgar na net, mas se
precisar de mais detalhes me envie um e-mail.

> Er Galvão Abbott
> Sócio-Fundador
> E-mail:
> gal...@phprs.com.br
> Skype/Gizmo:
> ergalvao
> MSN:

> ergal...@hotmail.com

> Visite meu blog
> sobre
> desenvolvimento
> web:http://blog.galvao.eti.br/
>
>
>
> > Abraços,
>
> > 2008/4/11 Er Galvão Abbott <gal...@phprs.com.br>:
>
> > "SQL was not made for hierarchical storage"
>
> > Olha, eu não sou expert em Banco de Dados, mas à não ser que
> > eu esteja sendo absolutamente ignorante (se eu estiver por
> > favor alguém me dê um tapa no ouvido hehe) essa frase que te
> > disseram é uma grande bobagem.
>
> > --
> > Fernando G. Norte
> > BHte - MG
> > cel:+55 31 9119 8814
> > -------------------------
> > MSN e Gtalk # fno...@gmail.com
>
>
>

> sigLogo.gif
> 1KExibirDownload

[Er Galvão Abbott]

Walker:

Primeiramente muito obrigado por iniciar um esclarecimento sobre a questão: era isso que eu estava querendo quando solicitei o "tapa" (hehe): a opinião de um especialista. É uma pena que não poderei estar em Brasília no dia 26, senão estaria na primeira fila.

Alguns esclarecimentos:

On Mon, 2008-04-14 at 05:16 -0700, Walker de Alencar wrote:
...

Indo aos fatos...

O Oracle tem suporte nativo.
PostgreSQL e MySQL, não possui nada para gerir isso, mas há como criar
metodologias que facilitem essa implementação.

A Grande questão é que não tem como vc ordenar a listagem de forma
hierárquica na consulta SQL apenas com esses campos: id, idroot, nome.

O problema prático aqui ocorre quando há mais de 2 níveis, correto? Porque a ordenação com dois níveis poderia ser feita através de um 

order by idroot, id;

Correto, ou estou ignorando algum ponto?

Vc precisaria de +1 campo para gerenciar isso, onde vc pode concatenar
a hierarquia, sem esquecer de usar um separador.

Perfeito.

Esse campo deve ser atualizado a cada inserção/update/deleção de
categorias, e em caso de deleção fazer uma checagem rigorosa quanto a
dependentes. Para nao ter categoria orfã.

Aqui fiquei com uma dúvida muito forte:

Até entendo que isso seria passível de ocorrer no MySQL, já que ele é um RDBMS que historicamente tinha diversas questões com Integridade Referencial (pessoal, sem Flame Wars nem indignações, isso é fato e não é o foco deste thread), mas no PostgreSQL isso aconteceria também? Quero dizer, já que é auto-relacionamento e é criada uma constraint pra isso, mesmo que fosse excessivamente trabalhoso para a base processar uma checagem recursiva ela não faria isso de qualquer forma?

Ainda estou concluindo o material para divulgar na net, mas se
precisar de mais detalhes me envie um e-mail.

Por favor quando você publicar isso me avise pois o assunto é interessantíssimo.

Grande abraço e obrigado mais uma vez,

www.phprs.com.br

Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao

MSN: erga...@hotmail.com

[Walker de Alencar]

Desculpe nao ter sido tão detalhista, é q o tempo anda curto... rs.

Esclarencendo:

A inviabilidadade de possuir apenas: id e iroot .

> O problema prático aqui ocorre quando há mais de 2 níveis, correto? Porque a
> ordenação com dois níveis poderia ser feita através de um
>
> order by idroot, id;
> Correto, ou estou ignorando algum ponto?

Está correto, o problema só acontece quando se tem mais de dois
níveis, alguns desenvolvedores acabam criando mais uma(ou mais)
tabela(s), mas o sistema nao deixaria de estar com limite de níveis
nas subcategorias. Seja 3 ou 4 Níveis.

> > Esse campo deve ser atualizado a cada inserção/update/deleção de
> > categorias, e em caso de deleção fazer uma checagem rigorosa quanto a
> > dependentes. Para nao ter categoria orfã.
>
> Aqui fiquei com uma dúvida muito forte:
>
> Até entendo que isso seria passível de ocorrer no MySQL, já que ele é um
> RDBMS que historicamente tinha diversas questões com Integridade
> Referencial (pessoal, sem Flame Wars nem indignações, isso é fato e não
> é o foco deste thread), mas no PostgreSQL isso aconteceria também? Quero
> dizer, já que é auto-relacionamento e é criada uma constraint pra isso,
> mesmo que fosse excessivamente trabalhoso para a base processar uma
> checagem recursiva ela não faria isso de qualquer forma?

Tirando a dúvida, realmente a parte de checagem deve ser feito no
MySQL. O PostgreSQL não permite a deleção já que há restrição definida
no constraint.

> > Ainda estou concluindo o material para divulgar na net, mas se
> > precisar de mais detalhes me envie um e-mail.
>
> Por favor quando você publicar isso me avise pois o assunto é
> interessantíssimo.

Estarei palestrando aqui em Brasília, mas estarei mandando a proposta
para o PHP Conference Brasil 2008. Mas qualquer coisa, se ocorrer
algum evento relacionado, me envie um convite, havendo disponibilidade
na data, terei o maior prazer em estar compartilhando o material.

[],s

[Pablo Madalena Targa]

> Tirando a dúvida, realmente a parte de checagem deve ser feito no
> MySQL. O PostgreSQL não permite a deleção já que há restrição definida
> no constraint.

Não entendi direito, esta dizendo que depois de dar DELETE na categoria pai eu teria que dar um UPDATE / DELETE nas categorias filhas e descendentes...

Em 14/04/08, Walker de Alencar <walker...@gmail.com> escreveu:

[Filipe Rosset]

Pablo Madalena Targa escreveu:

> > Tirando a dúvida, realmente a parte de checagem deve ser feito no
> > MySQL. O PostgreSQL não permite a deleção já que há restrição definida
> > no constraint.
>
> Não entendi direito, esta dizendo que depois de dar DELETE na
> categoria pai eu teria que dar um UPDATE / DELETE nas categorias
> filhas e descendentes...
>

Não seria o caso de usar ON DELETE CASCADE?
> Em 14/04/08, *Walker de Alencar* <walker...@gmail.com
> <mailto:walker...@gmail.com>> escreveu:

--
Filipe Rosset
Administrador e Consultor de Redes e Sistemas
filipe...@gmail.com
Chapecó - Santa Catarina

[Er Galvão Abbott]

Pablo, explicando:

O MySQL é um SGBD que originalmente não possuía uma preocupação muito grande com a parte de integridade referencial. Resumindo de forma bem simplificada, IR é a capacidade que o SGBD tem de impedir que um dado seja apagado se ainda houver referências à este dado dentro da base, por exemplo:

usuarios
-------------------------
id_usuario   nome
1                 Galvão
-------------------------

compras
----------------------------------------------
id_compra id_produto id_usuario
1                       8                   1
2                     58                   1
----------------------------------------------

Eu não poderia, seguindo o conceito de IR, apagar o usuário de id 1 se ele ainda "existe" na tabela de compras. Ou seja, antes de apagar um registro eu tenho que apagar todas as referências à este registro existentes na base.

Com o passar do tempo, IR começou à se tornar (IMHO já não era sem tempo), um assunto de maior "peso" no MySQL: foi introduzida a engine InnoDB que permitia um certo nível de IR, ainda longe de ser perfeito, mas antes isso do que nem isso. Mais tempo passou e isso melhorou consideravelmente de uns anos pra cá: Hoje, até onde eu sei (já explico) o MySQL possui uma IR bem mais robusta. Por ter tido toda essa característica de implementar a IR em versões mais recentes, é possível (presumo que foi isso que o Walker quis dizer) que haja um receio (comprovado ou não) de que, para a questão específica de auto-relacionamento, já que é uma relação "não muito comum", as rotinas de IR do MySQL ainda sejam falhas.

Walker, confirma?

"Explicando a explicação": Eu digo até onde eu sei porque me acostumei a trabalhar com outros SGBDs (especialmente PostgreSQL) porque na minha opinião a Integridade Referencial é vital em uma base de dados. É claro que já trabalhei e trabalho atualmente em projetos com MySQL mas até hoje eles são desenvolvidos em cima de bases completamente desprovidas de IR.

Eu acredito que essa realidade vá começar a mudar com a versão 6 do MySQL.

Espero ter esclarecido a questão.

Abraços,

www.phprs.com.br   Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao MSN: erga...@hotmail.com Visite meu blog sobre desenvolvimento web: http://blog.galvao.eti.br/

[Er Galvão Abbott]

Sim, isso à princípio seria uma solução, mas tem um problema grave: o CASCADE é uma solução "automatizada demais" para programadores.  E se é automatizada demais pra nós, pra usar em uma aplicação onde o usuário final deleta dados, por exemplo, é mais terrível ainda.

Exemplificando com uma situação propositalmente exagerada: Se você fizer uma base inteirinha baseada em CASCADE e todas as tabelas contiverem uma referência para uma chave primária específica, um DELETE CASCADE de um registro dessa chave pode resultar inclusive em tabelas completamente vazias, ou seja, em uma enorme perda de informações.

Existem termos mais técnicos do porque IR != CASCADE, mas honestamente nunca me aprofundei na teoria. Uma forma bem simplista de colocar a coisa toda seria que a IR serve como um alarme, um lembrete pra você de que existem mais referências dentro da base do que você imagina, enquanto que o CASCADE seria algo do gênero "Dane-se, apague tudo que eu encaro as consequências depois".

Abraços,

www.phprs.com.br   Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao MSN: erga...@hotmail.com Visite meu blog sobre desenvolvimento web: http://blog.galvao.eti.br/

P.S.: Apenas lembrando: A gente costuma falar de DELETE por ser a situação mais óbvia de risco, mas o UPDATE é tão perigoso quanto e também está envolvido na questão. Na realidade qualquer comando de "escrita" na base está envolvido.

[Pablo Madalena Targa]

Ok Galvão,

Tive essa dúvida pois coincidentemente estou desenvolvendo um projeto parecido com essas categorias, no meu caso é um menu que posso cadastrar pastas dentro de pastas e assim por diante, quando defini o ER do banco fiz este auto-relacionamento e estipulei que minha table usaria a engine InnoDB para não ter problemas de inconsistência.

Depois de realizar alguns testes fui limpar a base mas esqueci do relaciomento, então o banco chiou dizendo que existia uma FK que impedia isso.

Só pra esclarecer, valew!!!!

2008/4/14, Er Galvão Abbott <gal...@phprs.com.br>:

[Gustavo Segalla]

Com certeza,
Imagine deixar o usuário excluir um cliente e todos os seus pedidos serem excluídos junto...

Vale citar o Firebird/Interbase onde há IR à mui tempo....

Em 14/04/08, Er Galvão Abbott <gal...@phprs.com.br> escreveu:

--
Gustavo Segalla
e-mail: seg...@gmail.com
skype: gustavo.segalla
home page: www.segalla.com.br

[Filipe Rosset]

Gustavo Segalla escreveu:

> Com certeza,
> Imagine deixar o usuário excluir um cliente e todos os seus pedidos
> serem excluídos junto...
>
> Vale citar o Firebird/Interbase onde há IR à mui tempo....
>

> Em 14/04/08, *Er Galvão Abbott* <gal...@phprs.com.br
> <mailto:gal...@phprs.com.br>> escreveu:

>
> Sim, isso à princípio seria uma solução, mas tem um problema
> grave: o CASCADE é uma solução "automatizada demais" para
> programadores. E se é automatizada demais pra nós, pra usar em
> uma aplicação onde o usuário final deleta dados, por exemplo, é
> mais terrível ainda.
>
> Exemplificando com uma situação propositalmente exagerada: Se você
> fizer uma base inteirinha baseada em CASCADE e todas as tabelas
> contiverem uma referência para uma chave primária específica, um
> DELETE CASCADE de um registro dessa chave pode resultar inclusive
> em tabelas completamente vazias, ou seja, em uma enorme perda de
> informações.
>
> Existem termos mais técnicos do porque IR != CASCADE, mas
> honestamente nunca me aprofundei na teoria. Uma forma bem
> simplista de colocar a coisa toda seria que a IR serve como um
> alarme, um lembrete pra você de que existem mais referências
> dentro da base do que você imagina, enquanto que o CASCADE seria
> algo do gênero "Dane-se, apague tudo que eu encaro as
> consequências depois".
>
> Abraços,
>
>

> www.phprs.com.br <http://www.phprs.com.br/>
> * Er Galvão Abbott*
> Sócio-Fundador
> E-mail: gal...@phprs.com.br <mailto:gal...@phprs.com.br>
> Skype/Gizmo: ergalvao
> MSN: erga...@hotmail.com <mailto:erga...@hotmail.com>

> e-mail: seg...@gmail.com <mailto:seg...@gmail.com>
> skype: gustavo.segalla
> home page: www.segalla.com.br <http://www.segalla.com.br>
> >
Não digo para tudo, mas para várias coisas o CASCADE é bem útil.

[Massato Takaki]

Bom, vou dar a minha opinião.

Trabalho com análise de sistemas oracle.

 

ao definirmos se um relacionamento terá esta propiedade de CASCADE.

normalmente, acontece em bases nas quais usuários não podem excluir

 e sim em rotinas nas quais a exclusão é feita pelo sistema.

 

Em 14/04/08, Gustavo Segalla <seg...@gmail.com> escreveu:

--
Massato Takaki de Almeida
Tel: +55 (61) 8121-1740
--

[Er Galvão Abbott]

Sim, tudo existe por uma razão (Ok, estou virando filósofo heh).

O cascade é útil sim para alguns casos.

www.phprs.com.br   Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao MSN: erga...@hotmail.com

Visite meu blog sobre desenvolvimento web: http://blog.galvao.eti.br/

[Er Galvão Abbott]

Sim, mas aí você tem Stored Procedures e outras rotinas que garantem o bom funcionamento da coisa.

Enfim, não estou condenando o CASCADE, embora eu costume me expressar de uma maneira meio xiita de vez em quando heh

Abraços,

www.phprs.com.br   Er Galvão Abbott   Sócio-Fundador E-mail: gal...@phprs.com.br Skype/Gizmo: ergalvao MSN: erga...@hotmail.com Visite meu blog sobre desenvolvimento web: http://blog.galvao.eti.br/