Árvores Falsas: Usando Recuos para UIs Mais Simples

Artigo original ↗ Discussão no Hacker News ↗

Desenvolvedores debatem a prática de representar dados hierárquicos em UIs e bancos de dados usando “árvores falsas” — listas planas com recuo ou chaves parecidas com caminhos — em vez de estruturas explícitas de pai e filho. Defensores argumentam que essas abordagens são mais simples, performáticas e suficientes quando só é necessário um layout visual aninhado, recorrendo ao YAGNI para evitar complexidade prematura. Críticos contra-argumentam que essas codificações misturam apresentação com dados, complicam recursos futuros como operações em subárvores ou reordenação e ignoram técnicas bem estabelecidas de modelagem de árvores em bancos relacionais, como listas de adjacência, caminhos materializados, conjuntos aninhados e tipos especializados como o `ltree` do PostgreSQL.

Quando “árvores falsas” são apropriadas

  • Vários comentaristas observam que muitas UIs só precisam da aparência de hierarquia: uma lista plana com um nível de recuo muitas vezes é suficiente (por exemplo, sumários gerados a partir de títulos HTML, threads de comentários renderizadas via recuo).
  • Para esses casos, “árvores falsas” são elogiadas por serem mais simples, mais fáceis de implementar e amigáveis ao cache. O recolhimento pode ser feito iterando pelos irmãos até encontrar um recuo igual ou menor.
  • Alguns argumentam que isso se encaixa em uma mentalidade YAGNI: se hoje você só precisa de exibição aninhada, não construa em excesso a semântica completa de árvore.

Riscos, limitações e mudanças futuras

  • Muitos alertam que representar hierarquia visual no modelo de dados é “perigoso” e de visão curta.
  • Os usuários inferirão relações reais de pai–filho; pedidos por operações em subárvores, reordenação ou ações em lote costumam aparecer depois.
  • Críticos enfatizam que renomear ou excluir nós intermediários, impor pais válidos e mover subárvores pode ser estranho ou caro com codificações puramente visuais.
  • Vários dizem que o artigo minimiza esses problemas e exagera as desvantagens de árvores reais, chamando-o de superficial, parecido com desabafo ou caça-cliques.

Representações de árvore em bancos de dados

  • Vários modelos canônicos são mencionados:
    • Lista de adjacência (ID do pai).
    • Caminho materializado (por exemplo, a/b/c ou caminhos com pontos).
    • Conjunto aninhado / MPTT para consultas eficientes de subárvore.
  • PostgreSQL ltree e tipos de hierarquia do SQL Server são citados como opções nativas parecidas com caminho materializado, com observações sobre restrições de rótulos e ressalvas sobre pais ausentes.
  • Alguns sugerem armazenar primeiro a ordem/recuo e depois migrar para pai/filho mais tarde, já que a hierarquia pode ser reconstruída.

Desempenho e ferramentas

  • As experiências variam: CTEs recursivas são descritas tanto como “boas e divertidas” quanto como lentas ou pesadas em escala.
  • Blobs JSON aninhados são mencionados como outra “árvore falsa” que na verdade pode ser bastante fiel à estrutura lógica.
  • Há um meta-thread de que o conhecimento desses padrões (hierarquias no estilo Celko, técnicas SQL clássicas) está se tornando mais raro, em parte por causa de ORMs, NoSQL e menor ênfase em modelagem de dados.