Árboles falsos: usar sangrías para interfaces más simples

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores debaten la práctica de representar datos jerárquicos en interfaces y bases de datos usando “árboles falsos” —listas planas con sangría o claves tipo ruta— en lugar de estructuras explícitas padre-hijo. Quienes los apoyan argumentan que estos enfoques son más simples, eficientes y suficientes cuando solo se necesita un diseño visual anidado, apelando a YAGNI para evitar complejidad prematura. Los críticos responden que estas codificaciones mezclan presentación con datos, complican funciones futuras como operaciones sobre subárboles o reordenación, y pasan por alto técnicas bien establecidas para modelar árboles en bases de datos relacionales, como listas de adyacencia, rutas materializadas, conjuntos anidados y tipos especializados como `ltree` de PostgreSQL.

Cuándo son apropiados los “árboles falsos”

  • Varios comentaristas señalan que muchas interfaces solo necesitan la apariencia de jerarquía: a menudo basta con una lista plana más un nivel de sangría (por ejemplo, índices construidos a partir de encabezados HTML, hilos de comentarios renderizados mediante sangría).
  • Para estos casos, los “árboles falsos” se elogian por ser más simples, más fáciles de implementar y favorables a la caché. El colapso puede hacerse iterando entre elementos hermanos hasta encontrar uno con una sangría igual o menor.
  • Algunos sostienen que esto encaja con una mentalidad YAGNI: si hoy solo necesitas una visualización anidada, no sobreconstruyas una semántica completa de árbol.

Riesgos, limitaciones y cambios futuros

  • Muchos advierten que representar la jerarquía visual en el modelo de datos es “peligroso” y miope.
  • Los usuarios inferirán relaciones reales de padre e hijo; más adelante suelen llegar solicitudes de operaciones sobre subárboles, reordenación o acciones por lotes.
  • Los críticos enfatizan que renombrar o eliminar nodos intermedios, imponer padres válidos y mover subárboles puede resultar incómodo o costoso con codificaciones puramente visuales.
  • Varios dicen que el artículo minimiza estos problemas y exagera los inconvenientes de los árboles reales, calificándolo de superficial, tipo despotrique o clickbait.

Representaciones de árboles en bases de datos

  • Se mencionan varios modelos canónicos:
    • Lista de adyacencia (ID del padre).
    • Ruta materializada (por ejemplo, a/b/c o rutas con puntos).
    • Conjunto anidado / MPTT para consultas eficientes de subárboles.
  • PostgreSQL ltree y los tipos jerárquicos de SQL Server se citan como opciones nativas parecidas a rutas materializadas, con notas sobre restricciones de etiquetas y advertencias por padres ausentes.
  • Algunos sugieren almacenar primero el orden/la sangría y migrar después a padre/hijo, ya que la jerarquía puede reconstruirse.

Rendimiento y herramientas

  • Las experiencias difieren: las CTE recursivas se describen tanto como “bien y divertidas” como lentas o engorrosas a escala.
  • También se mencionan los blobs JSON anidados como otro “árbol falso” que en realidad puede ser bastante fiel a la estructura lógica.
  • Hay un subhilo meta sobre cómo el conocimiento de estos patrones (jerarquías al estilo Celko, técnicas clásicas de SQL) se está volviendo más raro, en parte debido a los ORM, NoSQL y a una menor atención al modelado de datos.