OT: Modelo de datos padre-hijos
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? -- 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
2008/8/27 roberto german puentes diaz <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
-- opino en http://blog.martinolivera.com.ar
On Thu, Aug 28, 2008 at 12:15 PM, Martin Olivera <[email protected]>wrote:
2008/8/27 roberto german puentes diaz <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
-- opino en http://blog.martinolivera.com.ar
_______________________________________________ Solar-tecnica mailing list [email protected] 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 ? ) :) 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
2008/8/28 roberto german puentes diaz <[email protected]>
On Thu, Aug 28, 2008 at 12:15 PM, Martin Olivera <[email protected]>wrote:
2008/8/27 roberto german puentes diaz <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
-- opino en http://blog.martinolivera.com.ar
_______________________________________________ Solar-tecnica mailing list [email protected] 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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
-- opino en http://blog.martinolivera.com.ar
On Mon, Sep 1, 2008 at 3:28 PM, Martin Olivera <[email protected]>wrote:
2008/8/28 roberto german puentes diaz <[email protected]>
On Thu, Aug 28, 2008 at 12:15 PM, Martin Olivera <[email protected]>wrote:
2008/8/27 roberto german puentes diaz <[email protected]>
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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
-- opino en http://blog.martinolivera.com.ar
_______________________________________________ Solar-tecnica mailing list [email protected] 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
participants (2)
-
Martin Olivera -
roberto german puentes diaz