SQL Land에서 도면 작성

실패를 공유하고 그 속에서 교훈을 얻는 정신에 따라 저는 여러분께 이야기를 하나 들려주고 싶습니다. 젊은 제가'똑똑한'시스템을 만들어 내용을 구성하는 데 도움을 주었습니다.이 경고 이야기는 주로 재미를 위한 것이지만 깔끔한 일과 고통스러운 교훈을 기록하여 나는 줄곧 배웠다.무고한 사람을 보호하기 위해 이름과 실체가 변경되었습니다.😜

하지만왜?

아주 오래 전에 먼 제품 팀에서 서적집을 위한 새로운, 더욱 유연한 차원 구조를 만드는 프로젝트가 있었다.처음에 우리의 데이터는 이렇게 설정되었다.

사용자는 서적집에 방문할 수 있다(이 예에서 "소설").한 소장집에는 몇 가지 장르가 포함되어 있고, 이 장르에는 개인 서적도 포함되어 있다.사용자는 모음의 모든 내용을 볼 수 있는 권한을 부여받을 수 있으며, 자신의 기준에 따라 책을 모음/분류할 수 있도록'읽기 목록'을 만들 수 있다.
이것은 매우 효과적이다. 사용자는 소장 중인 모든 소설을 볼 수 있고, 심지어는 이 책들을 개성화된 읽기 목록에 추가할 수도 있다.그러나 제품 팀은 새로운 제품군을 테스트하기 시작했습니다.

우리는 처음에 모든 사용자가 새로운'비소설'소장품에 접근하는 것을 허락하고 싶지 않았기 때문에, 우리는 단독으로 접근 권한을 부여했다.
우리는 몇 가지 문제가 있습니다. 주로 사용자는 한 번에 하나의 집합에서만 접근할 수 있고 읽기 목록을 만들 수 있습니다. 사용자는 UI에서 수동으로 전환해야 합니다.우리가 단지 하나의 집합만 있을 때, 이것은 매우 효과적이지만, 우리가 더 많은 집합을 추가하기 시작할 때, 유연성이 부족하다.또한 한 권의 책이 여러 개의 유파에 나타나면 그 항목은 복제되어야 한다. - 우리의 데이터 구조는 한 권의 유파가 여러 개의 유파가 있기를 기대하지 않는다😬 사용자들은 그들의 읽기 목록에 우리가 소장하지 않는 서적을 추가하는 것도 금지된다.만약 그들이 읽고 있는 내용을 추적하기 위해 원스톱 상점을 원한다면, 그들은 너무 재수 없다.
우리의 생각은 우리가 더 많은 소장품을 증가함에 따라 우리의 내용을 분류하고 중복을 피하는 더 좋은 방법이 필요하다는 것이다.조직 전체의 구성원들이 공동으로 노력하여 새로운 내용 구조를 만들었다.

우리는 우리의 내용을'소장'으로 분할하지 않고 모든 내용을 하나의 거대한 소장에 놓아'도서관'이라고 부르며 책이 다양한 장르로 출현하도록 허락한다.우리는 이것이 우리의 내용을 검색에서 더욱 쉽게 발견하고 중복을 줄이며 사용자가 소설과 비소설 제목을 포함하는 읽기 목록을 가질 수 있기를 바란다.

기술

우리는 이미 이 응용 프로그램에서 검증된 기술을 사용했다.

Postgres 데이터베이스(대부분의 SQL 데이터베이스는 데이터베이스 보기에 대해 어떤 형식의 지원이 있음)

ActiveRecord 응용 프로그램에서 ORM

으로 사용
현재 엔지니어로서 우리의 업무는 제품의 소망을 실현하고 동료에게 이런 새로운 모델과 상호작용하는 데 필요한 도구를 제공하는 것이다.우리는 하나의 선택이 있다. 우리는 표준 관계를 통해 서로 연결된 일련의 이산표를 만들 것인가, 아니면 새로운 것을 시도할 것인가?
(스포일러 경보-우리는 새로운 것을 시도했다.)

Ruby on Rails 진행 중인 그래픽

만약 우리가 이 새로운'세계관'을 만들려고 한다면, 우리는 이 과정에서 멋진 신기술을 사용하기를 희망한다. 공평하게 말하자면, 그것은 확실히 하나의 도형 모델처럼 현재의 용례에 잘 서비스를 제공할 수 있을 것 같다.우리는 우리의 실체와 관계가 무엇처럼 보일지 기대하는 개념을 제시했다.

만약 사용자가 원한다면, 그들은 자신의 책을 읽기 목록에 추가할 수 있지만, 이것은 그들이 도서관의 장서에 속한다는 것을 의미하지는 않는다.
완성된 후에 우리는 실현에 대해 토론했다. 우리는 그것을 어떻게 응용 프로그램에 도입할 것인가?이것은 우리의 현재 코드 라이브러리에 어떻게 적응합니까?일부 연구와 탐색을 통해 우리는 진정한 도형 데이터베이스(예를 들어 Neo4j, OrientDB 등)를 도입하는 것을 피하기로 결정했다.원가가 문제일 수 있습니다. 우리는 개발자가 와 anew concepts를 배우도록 강요하는 것을 피하고 싶습니다. 이 모델이 우리가 진정으로 견지하고 싶은 것이라고 확신할 때까지.
결정 후 관계 데이터베이스에 그래픽 엔티티와 관계식("노드"및 "모서리")을 저장하는 방법을 만들었습니다.
new query language

좋다

일단 우리가 새로운 차원 구조를 세우면 플러그인 관계는 간단해진다.우리는 더욱 높은 등급의 모델 (예를 들어 유형) 을 나무 모양의 JSON 표시로 쉽게 전환할 수 있다. (현실 세계에서 우리는 몇 개의 추가 등급 - 사고 유형, 하위 유형 등을 처리해야 하기 때문에 이것은 매우 유용하다.)

library.to_json
# => 
{
  id: 1,
  name: 'Library',
  genres: [{
    id: 1,
    name: 'Fantasy',
    books: [{
      name: 'Book 1',
      id: 10
    },{
      name: 'Book 2',
      id: 20
    }]
  }]
}

데이터와의 상호작용도 매우 간단해졌다. 우리의 노드는 모두 같은 속성을 가지고 있기 때문에 우리는 매우 통용되는 보기와 서비스를 이용하여 도서관과 읽기 목록에서 장르와 책의 모든 내용을 표시하고 작성하며 편집한다.

<h1>Editing <%= @node.name %></h1>
<%= render 'node-edit-form', node: @node %>

또 다른 장점은 도형 구조를 잘 이해할 수 있다는 것이다.우리는 그림을 훑어보는 방법, 그림을 필터하는 방법, 순환 인용을 검사하는 방법 등을 배웠다.

나쁘다

처음에는 모든 것이 좋았다. 모든 것이 똑같아 보일 때.그러나 얼마 지나지 않아 우리는 전단으로 보내는 유효한 하중에 추가 정보가 필요하다는 것을 발견했다.

# Our data model started to become more complex...
{
  id: 1,
  name: 'Library',
  genres: [{
    id: 1,
    name: 'Fantasy',
    book_count: 2,
    books: [{
      name: 'Book 1',
      available_for_checkout: true,
      author: 'Bob Bobberson',
      id: 10
    },{
      name: 'Book 2',
      available_for_checkout: false,
      author: 'Frances Farina',
      id: 20
    }]
  }]
}

우리는 도형 구조가 잘하는 일을 할 수 있도록 하는 것이 아니라 행위와 부가 속성을 라이브러리 차원 구조와 혼합하기 시작했다. 실체 간의 관계를 정의하는 것이다.우리는 과도한 범주화 보기에 필요한 논리를 복잡하게 하기 위해 단일 노드를 상세하게 토론하기 시작했다.이 보기들은 매우 빠르게 복잡해지고 노드 유형에 전환이 가득하다.

<h1>Editing <%= @node.name %></h1>

<% if @node.type == 'Genre' %>
  <p>Book count: <%= @node.book_count %></p>
  <%= render 'node-edit-form', node: @node %>
<% elif @node.type == 'Book' %>
  <%= render 'book-node-edit-form', node: @node %>
<% else %>
  <%= render 'node-edit-form', node: @node %>
<% end %>

시간이 지나면 우리의 응용 프로그램은 도형 데이터베이스라는 것이 분명하다. 우리는 그것을 도형 데이터베이스를 이용하여 데이터를 저장하는 서점이 아니라 서점의 모양으로 만들었다.우리의 코드 라이브러리는 지나치게 범용적이고 무의미한 방법과 컨트롤러로 가득 차 있어 고작 이해하기 어렵다.

# Instead of this...
def save_book(book_data)
  # Clearly saving a book to the DB
  save_to_graph(book_data) 
end

# we ended up with this:
def save_node(node_data)
  # What are we saving here??
  Nodes.save(node_data)
end

무서웠어

도서관 규모가 커지면서 조회가 엉망이 되었다.조회의 복잡성이 끊임없이 팽창하다.수백 차례의 조회를 피하기 위해서는 복잡한 사전 불러오기가 필요하다.우리의 많은 서비스는 정렬화된 JSON이나 집합 데이터를 생성하는 데 의존한다. 이것은 오류가 무엇인지, 오류의 원인과 추가 조회의 위치를 찾아내려고 할 때 심리적 비용을 증가시킨다.새로운 개발자들이 우리 팀에 합류했을 때, 그들은 우리가 하고 있는 일을 따라가기 더욱 어려웠고, 이것은 좌절을 초래했고 많은 시간을 낭비했다.우리는 귀속 SQL 보기와 무서운 "octo UI"(아래 참조) 관리 도구 같은 도구를 사용했는데, 이 도구들이 가져오는 슬픔은 즐거움보다 많다.

이 그림은 관리자와 그림의 상호작용을 허용하기 위해 우리가 실현한 편리한 관리 인터페이스와 유사하다

D3 샘플 라이브러리 마지막 볏짚

요컨대, 우리가 귀신을 포기하고 그것을 풀기 전에 이psuedo도 구조를 사용한 지 1년이 되지 않았다.주의해야 할 몇 가지 이유:

앞에서 말한 바와 같이 우리의 데이터 모델이 진화하면'노드'의 전체 개념을 위한 작성 서비스와 보기가 잘 작동하지 않는다

ActiveRecord는 관계 데이터베이스에 저장된 유사한 도형의 구조를 지원하지 않을 것이다. - 효율이 낮고 곤혹스러운 조회를 초래했다

가장 중요한 것은 우리가 (개발자로서) 이러한 개념을 쉽게 사용할 수 있도록 도구를 만들지 않았다는 것이다. 다른 개발자와 우리 제품의 최종 사용자에게는.

경험과 교훈

비록 나는 다시는 이렇게 하지 않겠지만, 나는 이 과정에서 확실히 뭔가를 배웠다.

귀속 보기 멋있어요.🤓

영원히 개인의 호기심을 남의 생계 앞에 두지 마라.

올바른 도구로 작업하기!

다음에 반짝이는 신기술을 찾고 회사의 일상적인 업무에 매우 중요한 제품에 사용하고 싶다는 것을 발견하면 당신의 선택을 꼼꼼히 고려하도록 격려합니다.

Do I even need INSERT SHINY THING HERE? ...do I really?

대부분의 경우 "새로운 이슈"가 아닌 "지루한 기술" 을 선택하는 것이 가장 적합합니다.수명이 길고 널리 이해되는 시스템이 아니라 흥미로운 혁신 기술을 선택해 왔다면, 새로운 엔지니어를 모집하고 시스템 전체를 유지하는 데 드는 비용/두통이 증가할 것이다.
나는 이것이 우리가 소프트웨어를 구축하는 모델에도 적용된다고 생각한다.우리가 도형 구조의 실현 세부 사항을 엉망으로 숨겼을 때, 우리는 직관적이지 않고 새로운 개발자들을 곤혹스럽게 하는 코드를 도입했다.만약 우리가 코드 격리 방면에서 더욱 잘한다면, 이후에는 더욱 쉽게'자제'버전을 진정한 버전으로 바꿀 수 있을 것이다.
Choose Boring Technology, Dan McKinley
위에서 링크한 글은 팀이 사용하는 기술 해결 방안의 수를 제한하는 데 좋은 이유를 제공했다.고장을 해결하고 자발적으로 개발한 해결 방안인 실제 사람의 문제를 유지하는 데 주력하는 것이 아니라 업무 문제 해결에 전념할 수 있다.익숙하지 않은 기술을 너무 많이 추가하면 대부분의 사람들이 합리적인 시간 안에 간단한 코드 라이브러리를 파악하지 않고 응용 프로그램이 어떻게 작동하는지 한두 명의 전문가 (오술 대가) 에게 알려줄 수 있다.
솔직하게 대답하면'이게 필요해요?'"예, 이것이 지금까지 제 문제를 해결하는 가장 좋은 해결 방안입니다."이렇게 할 수 있는 시간, 지원, 팀 대역폭과 전문 지식을 확보하십시오.만약 이 조건들이 모두 만족된다면, 당신은 당신의 연구를 해야 합니다. 이 일을 완성하기 위해 적당한 도구를 사용하십시오.🙇‍♀️