Estoy tratando de implementar una estructura tipo árbol utilizando un modelo de ruta materializada que se describe aquí: http://www.dbazine.com/oracle/or-articles/tropashko4.¿Exigir integridad referencial en la ruta materializada?
¿Es posible forzar la integridad referencial en el campo [ruta]? No veo cómo SQL podría hacerlo, ¿tengo que hacerlo manualmente en el DAL?
Sí, tiene que exigir la integridad de los datos usted mismo en el DAL cuando utiliza soluciones de ruta materializada o conjuntos anidados para datos jerárquicos.
La Lista de adyacencias es compatible con la integridad referencial, y esto también se aplica a un diseño al que llamo "Closure Table" (Tropashko denomina a este diseño "relación de cierre transitivo").
En el modelo de ruta materializada puede usar cadenas arbitrarias (tal vez cadenas unicode para permitir más de 256 hijos) en lugar de cadenas especiales de la forma "x.y.z". La identificación del padre es entonces la identificación de los hijos directos con el último carácter eliminado. Puede aplicar fácilmente esto con una restricción de comprobación como (mi ejemplo funciona en PostgreSQL)
check(parent_id = substring(id from 1 for char_length(id)-1)),
dentro de su mandato de creación de tabla. Si insistes en las cadenas de la forma "x.y.z", tendrás que jugar con expresiones regulares, pero supongo que es posible encontrar una restricción de verificación correspondiente.
Si desea hacer cumplir que las raíces tienen char_length (id) = 1, también puede agregar la comprobación de restricción ((parent_id es nulo) o (char_length (id) = 1)) a la definición de la tabla. – Whoever
"Ruta materializada" presentada por Vadim Tropashko en ese artículo, introduce la noción de orden en una relación ("Jones es el segundo miembro").
"Trayectoria materializada" no es más que "alguna forma de vista materializada" en el cierre transitivo, y por lo tanto sufre todos y exactamente los mismos problemas que cualquier otra "vista materializada", excepto que las cuestiones son algorítmicamente peores precisamente por el implicación de un cierre.
SQL es casi completamente impotente cuando las restricciones en un cierre están en juego. (Es decir: sí, SQL requiere que hagas todo tú mismo). Es una de esas áreas donde el RM muestra el máximo de su poder casi ilimitado, pero el SQL falla abismalmente y es una vergüenza que la mayoría de las personas confunde SQL por ser relacional.
(@Bill Karwin: Me gustaría poder darle +1 por su comentario sobre la relación entre la profundidad de los árboles y el resultado en el rendimiento. No existen algoritmos conocidos para calcular los cierres que funcionan bien en el caso de los árboles con profundidades "locos". es un problema algorítmico, no un SQL ni un solo relacional.)
EDITAR
Sí, RM = Modelo relacional
RM = modelo relacional? – hyperslug
+1 Sí, la ruta materializada es un ejemplo de desnormalización. Tiene algunos beneficios de eficiencia para ciertos tipos de consultas, pero sacrifica los beneficios de la RM, como la integridad referencial. –
Por cierto, puede pasar el puntero del ratón sobre una flecha hacia arriba invisible a la izquierda de un comentario y dar un pequeño refrendo al comentario. Sin embargo, eso no da puntos de repetición. –
Sí, podemos "hacer cumplir integridad referencial en el campo [ruta] ". Lo hice hace un par de años, se describe aquí:
Store your configuration settings as a hierarchy in a database
Gracias por la informacion, Bill. – hyperslug
Aquí hay un artículo sobre una solución de cierre transitivo: http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx @Bill Karwin: cómo se han desplegado los grandes conjuntos de datos usando "tablas de cierre" en OLTP/escenarios interactivos sin afectar el rendimiento problemas para inserciones? – nawroth
@nawroth: solo en el orden de miles de nodos en el árbol, punto tan bueno. Si necesitas representar árboles muy profundos, terminas con muchas filas. Si necesita representar muchos árboles poco profundos, es más modesto. –