▲

GN⁺: 가짜 나무: 더 간단한 UI를 위한 들여쓰기 사용

 (ratfactor.com)
4P by neo 11달전 | favorite | 댓글 1개

가짜 나무: 들여쓰기를 이용한 간단한 UI

  • UI에서 트리 형태의 목록을 원할 때, 부모-자식 관계를 구현하는 것이 많은 작업과 복잡한 데이터 구조를 필요로 함.
  • 관계형 데이터베이스에서는 재귀적 CTE(Common Table Expressions)를 사용하여 트리 구조 데이터를 얻을 수 있음.

데이터가 정말 트리 구조여야 하는가?

  • 항목들이 실제로 부모-자식 관계를 가져야 하는지, 아니면 단지 그렇게 보이기만 하면 되는지 고려 필요.
  • 실제 관계가 필요 없다면, 'id', 'sort', 'indent', 'name' 필드를 사용하여 트리를 간단히 저장할 수 있음.
  • 이 방식은 화면에 보이는 것을 그대로 표현하므로, 목록을 렌더링하고 편집하는 인터페이스를 만드는 것이 훨씬 간단함.

"네임스페이싱"을 사용한 또 다른 예

  • HissScript에서는 항목 이름에 점(".")이 있으면 첫 부분을 잘라내고 항목을 들여쓰기함으로써 네임스페이싱 기능을 구현.
  • 게임 편집기와 플레이어에게는 네임스페이싱이 중요하지만, 실제로는 단순한 이름일 뿐임.
  • 사람들은 종종 실제 트리 구조보다는 그것의 외관만 필요로 함.

보너스 트리-리스트

  • 실제 나무를 모방하여 경로와 정보를 평면 목록에 저장하고, 깊이 우선 또는 너비 우선 순회를 위해 경로를 정렬함.
  • 평면 목록은 일반적으로 작업하기 쉽고 컴퓨터에 적합함.

물리적 비유

  • 개인 스크랩북을 정리할 때, 사람에게는 그룹의 작동 방식이 명확하지만, 실제로 바닥에는 그러한 관계를 강제하는 물리적 메커니즘이 없음.

주의: 모든 상황에 맞는 해결책은 없음

  • 특정 시나리오에 맞게 기술을 적용해야 하며, 실제 트리 구조가 필요한 경우에는 트리를 사용해야 함.
  • 실제 항목 간의 관계를 알아야 할 경우에는 들여쓰기나 문자열 내의 기호를 세는 방식의 해킹을 사용하지 말 것.

GN⁺의 의견:

  • 이 기사는 소프트웨어 개발에서 복잡한 트리 구조 대신 시각적으로 단순한 들여쓰기를 사용하여 사용자 인터페이스를 단순화하는 방법을 제시함.
  • 개발자들에게는 데이터 구조를 단순화하여 개발 시간을 절약하고 유지보수를 용이하게 하는 효과적인 전략을 제공함.
  • 이 기사는 트리 구조가 항상 필요한 것은 아니며, 때로는 사용자에게 친숙한 시각적 구조만으로 충분하다는 점을 강조함으로써, 개발자들이 사용자 경험을 개선할 수 있는 새로운 관점을 제공함.
▲
neo 11달전  [-]
Hacker News 의견

  • 첫 번째 접근 방식인 '인접 리스트(adjacency list)'는 "분명히 유일한 방법"이라고 여겨지는 방식임.

  • 두 번째 방식은 "훨씬 간단한 방법"으로, 이전에 본 적 없는 방식이며 명백한 결점이 있지만, 어떤 경우에는 충분히 명확함.

  • 세 번째 방식인 '네임스페이싱(namespacing)'은 '구체화된 경로(materialized path)'라고 불림.

  • 트리를 표현하는 또 다른 방식으로 '중첩 집합(nested sets)'이 있으며, 이는 관계형 데이터베이스를 심각하게 다루던 시절에 잘 알려진 방식임.

  • Postgres는 'ltree'라는 데이터 타입과 검색 연산자를 제공하여, 트리 구조를 자연스럽게 다룰 수 있음. 예를 들어, 'ltree'를 사용하여 테이블을 생성하고 데이터를 삽입한 후 간단한 검색을 통해 트리 구조를 조회할 수 있음.

  • 구조 내의 값은 종종 표시된 트리가 아닌 데이터의 계층 구조임. 데이터를 순회하거나 관계를 보여주거나 재정렬하는 등의 작업을 수행하고 싶을 것임. 데이터베이스 내의 데이터 구조에 시각적 정보를 저장하는 것은 단기적인 시각으로 보일 수 있음.

  • 트리 형태의 데이터를 다루는 회사를 창업한 경험이 있음. 트리 구조를 O(n) 시간에 들여서 들여쓰기된 목록으로 변환하는 것이 가능함. 이는 인터뷰 질문 중 하나였으며, 재귀적 쿼리 없이도 트리의 일부를 빠르게 가져오고 렌더링할 수 있는 다양한 방법이 SQL 데이터베이스에 존재함.

  • SQL 쿼리를 사용하여 관계형 데이터베이스에서 트리 구조 데이터를 가져오는 한 가지 방법은 재귀적인 CTE(Common Table Expressions)를 작성하는 것임. CTE는 실제로 재미있으며, 한 번 익숙해지면 두려워할 것이 없음.

  • 사람들은 종종 실제로 트리를 원하지 않으며, 단지 트리의 외관만 필요로 함을 경험을 통해 배움. HN과 Reddit은 이 점에서 차이가 있음. HN에서는 자식 댓글이 부모 댓글의 다음 형제로, 들여쓰기를 부모의 들여쓰기에 하나를 더해 트리의 외관을 모방함. 반면 Reddit에서는 자식 댓글이 실제로 부모 댓글 내에 중첩됨.

  • 기사의 핵심 아이디어는 문제에 적합한 구조를 사용하는 것임. 그러나 이야기의 전개는 결함이 있음. 트리를 데이터베이스에서 검색하기 위해 CTE가 필요하지 않으며, 트리를 로컬에서 구성하기 위해 평면 목록을 가져올 수 있음. 또한, 충분히 큰 트리의 경우 가지를 이동하거나 깊이를 변경하고자 할 때 선형 비용이 발생할 수 있음.

  • 분류 체계나 다른 계층 구조를 설명할 때, 로컬 파일 시스템을 사용하는 간단하고 빠른 방법을 습득함. 'mkdir'와 'tree' 명령을 사용하여 이메일, 슬랙, pastebin 등에 붙여넣어 전달함.

  • 저장/로딩만 원한다면, 데이터를 원하는 방식으로 직렬화(예: JSON)하여 문자열로 저장하는 것이 더 단순한 해결책일 수 있음. 점 표기법을 사용하는 것은 VsCode 확장 프로그램인 Dendron이 이름 계층을 다루는 방식과 유사함.

  • 몇 년 전 OpenGL에 대한 비슷한 깨달음을 얻음: 계층적인 3D 객체의 세계를 그릴 필요가 없으며, 단지 정렬된 삼각형 목록을 그리면 됨. 이는 많은 최적화를 매우 쉽게 만듦.

답변달기