Señalaría que (funcionalmente) hay una GRAN diferencia entre ciclos y / o múltiples rutas en el ESQUEMA y los DATOS. Si bien los ciclos y quizás las trayectorias múltiples en los DATOS ciertamente podrían complicar el procesamiento y causar problemas de rendimiento (costo de manejo "adecuado"), el costo de estas características en el esquema debería ser cercano a cero.
Dado que la mayoría de los ciclos aparentes en los RDB ocurren en estructuras jerárquicas (organigrama, parte, subparte, etc.) es lamentable que SQL Server asuma lo peor; es decir, ciclo de esquema == ciclo de datos. De hecho, si estás usando restricciones de RI, ¡no puedes construir un ciclo en los datos!
Sospecho que el problema de trayectos múltiples es similar; es decir, múltiples rutas en el esquema no necesariamente implican múltiples rutas en los datos, pero tengo menos experiencia con el problema de múltiples rutas.
Por supuesto, si SQL Server no permite ciclos que aún estaría sujeta a una profundidad de 32, pero eso es probablemente adecuado para la mayoría de los casos. (¡Lástima que no sea una configuración de base de datos, sin embargo!)
Los disparadores "En lugar de Eliminar" tampoco funcionan. La segunda vez que se visita una tabla, se ignora el activador. Entonces, si realmente quieres simular una cascada, tendrás que usar procedimientos almacenados en presencia de ciclos. Sin embargo, el disparador en lugar de eliminar funcionaría para casos de múltiples rutas.
Celko sugiere una "mejor" forma de representar las jerarquías que no introduce ciclos, pero hay compensaciones.