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

Mar Sep 2 03:41:32 CEST 2008

On Mon, Sep 1, 2008 at 3:28 PM, Martin Olivera <molivera en solar.org.ar>wrote:

>
>
> 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 ||
>
>

Sip es una opcion conocida como "MaterializedPath" y es otra muy buena para
los planes de cuentas junto a nested set model...
gracias por los aportes ... veo que no voy muy errado
saludos
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: /pipermail/solar-tecnica/attachments/20080901/aab48fed/attachment.htm