Recursividad en XML

Si tienes sql2005 puedes usar tanto xquery como xpath para acceder a tu tipo
de datos xml, otra cosa muy distinta es que lo que planteas pueda o no ser
buena idea, que con los datos que nos das no podemos decirte.
No me entiendas mal, no estoy cuestionando que esté bien o mal, solo intento
que se vea que el problema no parece trivial y que lo que nos enseñas no es
más que el punto final resultado de tus conclusiones en base a unos
requisitos que solo tu conoces. Igual no hay otro remedio que hacerlo así,
pero igual, si nos planteas el problema en su globablidad alguno ya lo ha
resuelto de otra forma, igual dentro o igual fuera de la base de datos.


Saludos
Miguel Egea
"Marianoh" wrote in message
news:
Hola a todos:

Estoy trabajando en un módulo que consulta una BD segun criterios
agregados por el usuario.

Este tiene la posibilidad de agrupar las condiciones en grupos y a
la vez definir operadores 'y' u 'o' entre las condiciones y entre los
grupos.

Esta selección de criterios la represento en un XML, por lo que la
cantidad de elementos y anidamientos varian.

Pienso usar SQL dinámico para crear la consulta, pero entiendo que
con OPENXML no puedo recorrer recursivamente los nodos de un XML, lo
que me obligaría a contatenar el WHERE de la consulta en la
aplicación.

Quisiera saber si esto es correcto o si SQL 2005 me ofrece alguna
posibilidad. El rendimiento no es tan importante en este caso dado que
son pocas consultas.

Saludos y gracias por sus opiniones.

Mariano

Miguel, gracias por responder, entiendo tu planteo.

Por lo pronto con Xpath y Xquery parece ser (hasta donde he
investigado) que no es posible, asique lo resolví concatenando el
WHERE de la sentencia desde la aplicación, igualmente comento con más
detalle ya que cualquier observación me es bienvenida:

El requerimiento es un módulo de consultas que permita hacer busquedas
customizadas generadas por los propios usuarios, esto sobre un modelo
de 10 tablas, de las cuales 9 (digamos Personas, Contratos,
Presupuestos, etc) tienen un FK a la PK de la restante (Proyectos)

Las búsquedas deben arrojar un simple listado de proyectos que cumplan
con los criterios especificados por el usuario. Los usuarios no
manejan SQL, pero si requieren un cierto nivel de complejidad en las
búsquedas.

Lo que hemos planteado es una interface donde el usuario agrega
criterios (por ej. elije PERSONA, luego, de los campos de la tabla
PERSONA, elije ROL, y especifica un valor, digamos 'OPERARIO', luego
puede hacer lo mismo con el apellido, nombre, etc. o seleccionar otra
tabla y repetir la operacion cuantas veces quiera).

Me piden realizar búsquedas del tipo, "Proyectos en los que haya
participado el operador 127 y que tengan contrato clase 'B', o que
tengan contratos clase 'A' y en los que hayan participado los
operadores 127 y 432"

Como vez, la cosa viene complicada (aunque va marchando). Para expresar
esto en pantalla utilizamos un árbol donde las ramas son operadores
lógicos ("Y"/"O") y las hojas criterios, permitiendo que debajo de
cada operador lógico haya critrerios u otro operador.

En base a esto se genera un XML con la misma estructura, que es el que
uso para concatenar el WHERE de la sentencia, por medio de un método
recursivo que itera los nodos y los transforma en SQL, lo que ya
funciona para las consultas mas sencillas.

Por supuesto he tenido que tomar algunas precauciones para la
injección de sql.

Cualquier comentario de quien haya tenido que generar este tipo de
consultas dinámicamente es bienvenido, y si alguién tiene que hacer
algo parecido no dude en consultarme. dejo algunos links que me han
sido útiles:

un clásico sobre SQL dinámico:
http://geeks.ms/blogs/cfouz/archive...16/66.aspx

bastante gráfico:
http://www.sommarskog.se/dyn-search.html

xquery:
http://www.15seconds.com/issue/050803.htm

saludos.

Es un problema muy común, creo que lo que haces es correcto, si quieres un
consejo de como yo lo haría para que falle poco (ojo, seguramente tu lo
estás haciendo magnificamente, esto es solo mi reflexión), tendrías que
definir una gramática, como si fueses un compilador y determinar cuales
expresiones son válidas en tu entorno. El resultado de tu "compilación "
debiera ser uaa sentencia SQL. Cuanto más experiencia en SQL Tengas tanto
más optima será esa consulta. Yo hace mucho que no hago nada parecido, pero
como ejercicio para desoxidarme publiqué esto en portalsql que es la versión
más simple de esto que comento
http://www.configuracionesintegrale...?articuloc
escrito para tsql y esto otro que es lo mismo, pero en VB,
http://www.configuracionesintegrale...?articulo8
en su momento disfruté aprendiendo y usando esto (para mi desgracia
muchísimo antes de esta fecha :p), y he hablado con algún buen amigo del
tema y me ha encantao la conversación (además de ser buena técnicamente
hablando), por ejemplo este amigo usó esto para hacer un "compilador difuso"
con instrucciones de HazHastaQueTeCanses {}, RepiteCuantoQuieras y cosas así
:). El caso es que no es una idiotez, sino una forma de implementar eso se
que creo te podrán servir para generar código SQL sin que el proceso sea un
dolor auténtico lleno de "funciona casi siempre".

Espero que te ayude.

Saludos
Miguel Egea

"Marianoh" wrote in message
news:
Miguel, gracias por responder, entiendo tu planteo.

Por lo pronto con Xpath y Xquery parece ser (hasta donde he
investigado) que no es posible, asique lo resolví concatenando el
WHERE de la sentencia desde la aplicación, igualmente comento con más
detalle ya que cualquier observación me es bienvenida:

El requerimiento es un módulo de consultas que permita hacer busquedas
customizadas generadas por los propios usuarios, esto sobre un modelo
de 10 tablas, de las cuales 9 (digamos Personas, Contratos,
Presupuestos, etc) tienen un FK a la PK de la restante (Proyectos)

Las búsquedas deben arrojar un simple listado de proyectos que cumplan
con los criterios especificados por el usuario. Los usuarios no
manejan SQL, pero si requieren un cierto nivel de complejidad en las
búsquedas.

Lo que hemos planteado es una interface donde el usuario agrega
criterios (por ej. elije PERSONA, luego, de los campos de la tabla
PERSONA, elije ROL, y especifica un valor, digamos 'OPERARIO', luego
puede hacer lo mismo con el apellido, nombre, etc. o seleccionar otra
tabla y repetir la operacion cuantas veces quiera).

Me piden realizar búsquedas del tipo, "Proyectos en los que haya
participado el operador 127 y que tengan contrato clase 'B', o que
tengan contratos clase 'A' y en los que hayan participado los
operadores 127 y 432"

Como vez, la cosa viene complicada (aunque va marchando). Para expresar
esto en pantalla utilizamos un árbol donde las ramas son operadores
lógicos ("Y"/"O") y las hojas criterios, permitiendo que debajo de
cada operador lógico haya critrerios u otro operador.

En base a esto se genera un XML con la misma estructura, que es el que
uso para concatenar el WHERE de la sentencia, por medio de un método
recursivo que itera los nodos y los transforma en SQL, lo que ya
funciona para las consultas mas sencillas.

Por supuesto he tenido que tomar algunas precauciones para la
injección de sql.

Cualquier comentario de quien haya tenido que generar este tipo de
consultas dinámicamente es bienvenido, y si alguién tiene que hacer
algo parecido no dude en consultarme. dejo algunos links que me han
sido útiles:

un clásico sobre SQL dinámico:
http://geeks.ms/blogs/cfouz/archive...16/66.aspx

bastante gráfico:
http://www.sommarskog.se/dyn-search.html

xquery:
http://www.15seconds.com/issue/050803.htm

saludos.

Nuevamente gracias por responder Miguel.

Leí (un poco por arriba) los artículos que publicaste y son muy
interesantes, El problema es similar con la diferencia que se "viene"
desde la sentencia y yo tengo que contruirla. En ese sentido me ayuda
bastante contruir el modelo con formato XML, ya que usando recursividad
es más facil construir la sintaxis sql y respetar los operadores
lógicos.
Como bien decís es un trabajo más que interesante, (aunque mejor
sería hacerlo sin presiones de projucción, je) Lo que estoy tratando
de buscar es un equilibrio entre funcionalidad y complejidad, y
coincido en que cuanto más se sabe de sql menos dificil es.
Lamentablemente no es mi especialidad, aunque a este paso dentro de
poco.
Para otras dudas en cuanto a las consultas habró nuevos hilos, y si
alguien quiere comentar o preguntar, bueno, aca está este!

Saludos: Mariano