[Solar-tecnica] OT: Modelo de datos padre-hijos

Lun Sep 1 20:28:00 CEST 2008

2008/8/28 roberto german puentes diaz <puentesdiaz en gmail.com>

>
>
> On Thu, Aug 28, 2008 at 12:15 PM, Martin Olivera <molivera en solar.org.ar>wrote:
>
>>
>>
>> 2008/8/27 roberto german puentes diaz <puentesdiaz en gmail.com>
>>
>>> Una consulta un poco descolgada, pero se que en la lista hay gente que la
>>> hace de goma.
>>> Para modelos de datos Padre - hijos ... ejemplo un Plan de Cuentas
>>> Contables, o sistema de genealogia, o cualquier cosa que no limite los
>>> niveles de pertenencia ni la cantidad de nodos que puede tener un nodo
>>> padre....
>>>
>>> Para una app web. El nested set model
>>> (http://dev.mysql.com/tech-resources/articles/hierarchical-data.html)
>>> es una de las mejores soluciones. O acaso se puede pensar en algo
>>> radicalemtne mejor?
>>>
>>
>> el patron de disenho para eso se llama Composite, lo que muestran ahi es
>> una posible implementacion en Base de datos, la mas sencilla;
>>
>> Busca composite y vas a encontrar diversas implementaciones posibles de
>> ese patron
>>
>> en realidad un esquema de arbol es mas simple que un composite, una unica
>> clase con una relacion consigo misma, que en un sentido es unica (un solo
>> padre) y en el otro es multiple (muchos hijos). Esa es l implementacion que
>> ahi hacen.
>>
>> Para saber si es la mejor o no, es necesario saber que tipo de consultas
>> se requieren, porque por ejemplo encontrar la cadena de antecesores o la
>> cadena de descendientes de un nodo determinado se debe hacer iterativamente
>> en ese modelo. Si solo vas a quere buscar padre de un nodo o hijos de un
>> nodo es lo mejor
>>
>>
>>
>>>
>>>
>>> --
>>> Cr. Puentes Diaz
>>>
>>> www.puentesdiaz.com.ar/blog/novedades
>>> www.puentesdiaz.com.ar/blog/propiedades
>>> www.puentesdiaz.com.ar/blog/curriculum-vitae
>>>
>>> Linux User n° 441474
>>>
>>> _______________________________________________
>>> Solar-tecnica mailing list
>>> Solar-tecnica en lists.ourproject.org
>>> https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
>>>
>>>
>>
>>
>> --
>> opino en http://blog.martinolivera.com.ar
>>
>> _______________________________________________
>> Solar-tecnica mailing list
>> Solar-tecnica en lists.ourproject.org
>> https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
>>
>>
> Revisando los pareones en
> http://en.wikipedia.org/wiki/Category:Software_design_patterns
>
> encontramos
>
> http://en.wikipedia.org/wiki/Hierarchical_visitor_pattern
> http://c2.com/cgi/wiki?HierarchicalVisitorPattern
>
> La necesidad de datos, haceque un nodo , deba conocer sus hijos inmediados
> (claro esta) y todos sus nodos recursivamente.
> En un Plan de Cuentas. es importante el armado del arbol, asi como el
> computo de saldos.
> Tambien es importante saber a que rama de nodos pertenece....
>
> Y como se trata de una aplicacion web, seguramente tendra mucha intesidad
> en las consultas (en forma recursiva)
>
> Por eso consultaba sobre algun ejemplo recomendado  para la DDBB ( DER ? )
> :)
>

si vas a tener que sacar a menudo toda la descendencia de un nodo, tal vez
te convenga guardar un registro de las claves estructurales, tipo VARCHAR
clave = "1.2.1.15.4.22.12", en cada nodo

eso te va a permitir muy facil buscar todos los hijos de un nodo serian los
*where clave like clave || '%'* o *where clave like CONCAT(clave, '%') *si
usas MySQL por ej y no soporta concatenar con ||


>
> saludos
>
>
> --
> Cr. Puentes Diaz
>
> www.puentesdiaz.com.ar/blog/novedades
> www.puentesdiaz.com.ar/blog/propiedades
> www.puentesdiaz.com.ar/blog/curriculum-vitae
>
> Linux User n° 441474
>
> _______________________________________________
> Solar-tecnica mailing list
> Solar-tecnica en lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
>
>


-- 
opino en http://blog.martinolivera.com.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: /pipermail/solar-tecnica/attachments/20080901/6d4df035/attachment.htm