datos jerárquicos en una base de datos: tablas recursivas de consulta vs. cierre contra base de datos de gráficos

Question

Estoy comenzando un nuevo proyecto que tiene algunos datos jerárquicos y estoy buscando todas las opciones para almacenar eso en una base de datos en este momento .

Estoy usando PostgreSQL, que permite las consultas recursivas. También busqué patrones de diseño para bases de datos relacionales, como closure tables y eché un vistazo a las soluciones de base de datos de gráficos como neo4j.

Me resulta difícil decidir entre esas opciones. Por ejemplo: dado que mi RDBMS permite consultas recursivas, ¿tendría sentido usar tablas de cierre y cómo se puede comparar con las soluciones de base de datos de gráficos en términos de mantenimiento y rendimiento?

Cualquier opinión/experiencia sería muy apreciada!

Answer 1

La mesa de cierre de todo es redundante si se puede usar consultas recursivas :)

Creo que es mucho mejor tener una consulta recursiva complicada que tiene que averiguar una vez que el trato con el IO extra (y espacio en disco) de una tabla separada y disparadores asociados.

He hecho algunas pruebas simples con consultas recursivas en postgres. Con unos pocos millones de filas en la tabla, las consultas seguían siendo < 10ms para devolver todos los padres de un niño en particular. El regreso de todos los niños también fue rápido, según el nivel del padre. Parecía depender más de que el disco IO captara las filas en lugar de la velocidad de la consulta en sí. Esto se hizo por usuario único, por lo que no estoy seguro de cómo funcionaría bajo carga. Sospecho que todavía sería muy rápido si también puedes mantener la mayor parte de la tabla en la memoria (y configurar postgres correctamente). Agrupar la tabla por ID padre también pareció ayudar.

Answer 2

El campo de nivel ("profundidad") de la tabla de cierre es redundante. Solo se necesita una consulta recursiva para calcularlo. Eso lo resume todo.