¿Alguien está usando HierarchyId en producción real con tablas de tamaño razonable, más de unos pocos miles de filas? ¿Es confiable / eficiente? Hasta ahora no he encontrado a nadie que no esté afiliado con el vendedor, lo recomiende, y Paul Nielsen desaconseja aquí .
¿Cuál es su experiencia con el uso de HierarchyId en sistemas de producción reales?
¿Qué criterios usaste cuando elegiste HierarchyId sobre sus alternativas?
Respuestas:
Implementé HierarchyID y descubrí que proporciona un buen rendimiento y es fácil de usar.
Lo he usado en conjuntos de datos relativamente pequeños (decenas de miles de filas) con jerarquía de hasta 10 ramas de profundidad.
¿Por qué usarlo? El tipo HierarchyID proporciona una serie de métodos auxiliares (como IsDescendantOf) que hacen que su trabajo sea más fácil que rodar su propia ruta materializada.
El comentario de Paul Nielsen sobre StackOverflow me resulta confuso: el HierarchyID es un camino materializado. Estoy más inclinado a estar de acuerdo con este comentario debajo de su respuesta.
Una mejor pregunta podría ser "¿por qué no usarlo?". Es fácil de usar, proporciona una gran cantidad de funcionalidades que de otro modo estarías escribiendo para ti y funciona bien (en mis pruebas limitadas).
Esta es una respuesta a la pregunta de Kirk 'por qué no usarlo (HierarchyId)'. En comparación con la ruta materializada, en algunos casos importantes, HierarchyId parece ser menos eficiente y menos conveniente para trabajar.
La razón es simple: citando el comentario de Microsoft sobre Connect , "El problema es que las llamadas CLR, incluidos los métodos de JerarquíaID, son opacas para el optimizador de consultas. Esto es así por diseño. Sin embargo, significa que la estimación de la cardinalidad para ellos a veces puede ser bastante incorrecto."
Por otro lado, implementar la ruta materializada es muy fácil la primera vez que necesitamos hacerlo, y la próxima vez es esencialmente una tarea de copiar y pegar. Por lo tanto, obtenemos una solución más versátil y de mejor rendimiento con muy poco esfuerzo.
Así que estoy completamente de acuerdo con Paul Nielsen, quien escribió en su excelente libro titulado "Microsoft® SQL Server® 2008 Bible" de la siguiente manera: "El nuevo HierarchyID no está exento de controversia. Es nuevo y tiene mucha prensa y tiempo de demostración, pero yo" No estoy seguro de que sea un problema que necesita otra solución ".
Mi empresa utiliza HeirachyID en ventas directas, software de marketing multinivel. Funciona. Realmente no he trabajado con él, solo sé que lo estamos usando.
El mayor problema que he visto con él es que estamos iterando a través de los niveles en forma de bucle en lugar de estar más basados en conjuntos. En esa área no funciona muy bien para nosotros, pero no estoy seguro de si eso es un problema con el tipo o nuestra implementación.
Un problema con la jerarquía es que obtiene el bloqueo del proveedor. Pero encontré un gran artículo de Adam Milazzo sobre cómo funciona todo internamente:
http://www.adammil.net/blog/view.php?id=100
Con esto pude escribir un script de Postgres para convertir mi conjunto de datos desde MSSQL. También lo incluí en un script que escribí para importar la base de datos AdventureWorks a Postgres:
https://github.com/lorint/AdventureWorks-for-Postgres
Simplemente busque "jerarquía" en el archivo install.sql allí y pronto encontrará referencias para convertirlo.
Nuestro equipo lo implementó en producción, al principio el rendimiento es bueno, después de 2 años, la tabla ahora contiene 430,000 filas y getroot y getdecendent toma 3 segundos, ambos son necesarios para calcular el siguiente valor de Id para insertar el registro. Ahora, una sola inserción de subárbol tarda aproximadamente 16 segundos, lo cual no es aceptable en absoluto.