아! 이제 이해했어요! 이게 어떤 형태일지 아이디어가 있을까요? 우리는 항상 여기에서 더 쉽게 만들 방법을 찾고 있습니다 
2개의 좋아요
물론이죠! Northwind(MS Access로 유명한!) 데이터 모델 같은 것을 사용하는 것이 훌륭할 것입니다. Postgres 스키마를 조사하여 이를 생성하는 도구가 있을 수도 있습니다.
2개의 좋아요
초보자에게 설명하듯이 공유해 주실 수 있을까요? 예를 들면:
- 이 기능을 추가하면 어떤 문제를 해결할 수 있을까요?
- 추가된다면 어떤 모습으로 보일 거라고 예상하시나요?
결국 제 제안에 대해 더 자세한 설명을 요청하는 것입니다. (가능하면 최대한 자세히요 
) 다음에 오실 데이터 아키텍트분들의 경험을 개선할 수 있도록요. 저는 데이터에 대한 배경 지식이 전혀 없어서, 자세한 제안이 큰 도움이 될 거예요
2개의 좋아요
하하, 오시오님,
정말 공평한 지적이네요! 인정합니다…
대부분의 데이터베이스 관련 종사자(데이터 아키텍트만 아니라 개발자들도!)는 서로 다른 테이블이 어떻게 연결되어 있는지 보여주는 데이터 모델이 있으면 매우 유용하다고 느낍니다.
예를 들어, 제 쿼리를 생각해 보면 :), 저는 특정 사용자에 대한 여러 가지 정보가 필요했습니다. 제가 필요로 한 사용자는 다음과 같은 조건을 만족해야 했습니다:
- 특정 그룹에 속해 있거나(또는 속해 있지 않거나)
- 특정 토픽을 해결했으며
- 특정 날짜 범위 내에 해당해야 했습니다
위 질문에 답하기 위해서는 users 테이블, user_actions 테이블, groups 테이블이 필요합니다. 데이터 모델이 있었다면, 사용자가 user_id를 통해 user action과 연결되고, primary_group_id/id를 통해 그룹과 연결된다는 것을 시각적으로 보여줬을 것입니다.
이는 어떤 데이터가 사용 가능한지뿐만 아니라, 특히 복잡한 쿼리가 포함된 경우 어떻게 조인(join)해야 하는지 시각화하는 데 도움이 됩니다.
데이터 탐색기에서 모든 테이블을 클릭하며 어떤 필드가 사용 가능한지 확인하고 잊지 않도록 적어 내려가는 방법도 있지만, 데이터 모델이 있는 것이 우리 중 일부에게는 훨씬 더 인간적인 방법일 수 있습니다
5개의 좋아요
아! 또 걸렸네요! 
저는 기술적인 배경이 없어서 이게 명확하지 않았습니다. 하지만 필요성은 이해하니까, 네. 데이터 모델이 도움이 될 것 같습니다. 제가 해볼 수 있는 게 있는지 알아볼게요.
그동안 이 대화를 Contribute > Site feedback 카테고리의 새 토픽으로 옮겼습니다. 다른 토론은 깔끔하게 유지하기 위해서입니다.
2개의 좋아요
정말 멋질 것 같아요, 감사합니다!
1개의 좋아요
팀과 이야기해 본 결과, 여러 가지 이유로 이 작업이 쉽지 않다는 것을 알게 되었습니다. 또한 이 주제가 더 잘 드러나도록 Contribute > Feature 채널로 옮겼습니다.
현재 데이터 관련 업무를 담당하는 우리 팀원들은 대부분 소스 코드에서 사용할 수 있는 모델들을 주로 사용하고 있습니다:
Northwind 데이터 모델도 살펴볼 기회가 있었습니다:
이 모델은 이해하기 쉽고 종이 한 장이나 화면 하나에 담기에도 충분합니다. 테이블이 총 13개입니다.
Discourse와 비교해 보면, 우리는 180개 이상의 훨씬 더 많은 테이블을 가지고 있으며, 이를 시각화하는 것은… 상당한 여정이 될 것입니다. 특히 플러그인에서 비롯된 테이블(설치 환경마다 달라질 수 있음)과 *_custom_fields 테이블에 포함된 데이터까지 포함해야만 완전한 그림을 얻을 수 있기 때문입니다.
또한 데이터베이스 설계 방식 때문에 대부분의 데이터 모델링 도구를 사용할 수 없으며, ActiveRecord 모델과 호환되는 도구를 찾아야 합니다. 그리고 솔직히 말하자면, 이런 데이터 관련 논의는 제 수준을 넘어섭니다.
하지만 그렇다고 해서 이 작업을 원하지 않는다는 뜻은 아닙니다. 단지 현재 상황에 대한 코멘트를 남기는 것입니다. 이 부분을 더 잘 개선할 수 있는 방법에 대해 여러분이나 다른 분들의 제안을 듣고 싶습니다.
6개의 좋아요
그것 자체의 방대한 규모, 외래 키의 부재, 그리고 RDMS에 거의 로직을 남기지 않는다는 점 때문에, Discourse 소스 코드를 읽지 않고는 Discourse DB를 이해하기가 쉽지 않아서 실제로는 그렇게 유용하지 않습니다.
하지만 정말 필요하시다면, RubyMine이 이를 생성해 줄 수 있습니다.
14개의 좋아요
rails-erd를 사용하여 관계가 포함된 ERD를 생성할 수 있습니다: GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications · GitHub
다만, 이것이 얼마나 유용할지는 확실하지 않습니다.
10개의 좋아요
@lju 저희 설명이, 특히 추가된 맥락을 포함해, 도움이 되기를 바랍니다. 이 이슈를 1~2일 내에 닫을 예정입니다. 그래도 더 자세한 정보가 필요하시면 언제든 질문해 주세요.
3개의 좋아요
@osioke 님, 안녕하세요.
답변이 늦어서 죄송합니다. 최근 일이 좀 많았습니다.
도움이 될 만한 아이디어가 몇 가지 있습니다. 며칠만 주시면 정리해서 보내드리겠습니다.
감사합니다.
Lju
1개의 좋아요
훌륭합니다! 며칠 전부터 사용하고 계신 거죠 이 문제에 관심을 가져 주셔서 감사합니다.
안녕하세요,
제 의견은 데이터 모델이 유용할 수 있지만, 반드시 모든 테이블을 포함할 필요는 없다는 것입니다. 전체 쿼리의 90% 이상이 사용하거나 사람들이 찾는 핵심 테이블은 대략 15~25개 정도일 것으로 추정됩니다. 실제로 제공되는 다양한 테이블을 살펴보면, 탐색하려는 쿼리/데이터 유형을 기반으로 여러 데이터 모델을 생성할 수 있을 것입니다.
향후 며칠간 가장 자주 쿼리되는 테이블들을 정리해 보겠습니다. 이는 광범위한 연구가 아니라 단순한 추측에 불과할 것입니다. 데이터 탐색(Data Explorer) 카테고리에서 제기된 다양한 질문들도 인기 있는 테이블을 잘 보여줄 것입니다.
또한, 사용 가능한 데이터의 서로 다른 부분을 탐색하기 쉽게 하기 위해 관심 '존(zones)'을 나타내는 별도의 다이어그램을 추가할 수도 있습니다.
이해가 되시나요?
감사합니다,
Lju
6개의 좋아요
데이터 탐색기(Data explorer)에서는 쿼리 편집 UI 패널에 가장 중요한 9개 테이블을 먼저 나열하며, 클릭 한 번으로 모든 테이블의 컬럼 구조와 타입을 확인할 수 있습니다:
3개의 좋아요
그러면 그 9개의 테이블을 단순화된 데이터 모델로 전환할 수 있을까요? 
5개의 좋아요
네, 결과를 공유해 주세요!
4개의 좋아요
와, 이건 정말 방대하네요. 온라인에서 본 DB 스키마 중에서도 가장 큰 규모 중 하나인 것 같습니다.
혹시 https://dbdiagram.io로 만든 건가요? 다이어그램의 공개 URL을 공유해 주실 수 있을까요?
이 테이블들 간의 관계와 연결 구조에 더 관심이 있습니다.
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
감사합니다
매우 유용하지만, 테이블 간 관계와 테이블의 기본키/외래키를 확인할 수 있는 공유 가능한 URL이 있으면 좋겠습니다.
스키마에 1:1 관계가 있나요? 특히 users 테이블과 user_options 테이블 사이의 관계에 대해 알고 싶습니다.
이 테이블들 간의 관계에 대해 도와주실 분 계신가요? 스키마 다이어그램 기준입니다.
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
1:1 관계가 있는지 궁금합니다.
도와주시면 감사하겠습니다. 감사합니다
주로 1:N 관계입니다. 사용자는 여러 알림, 인증 토큰 등을 가질 수 있기 때문입니다.
user_options만 1:1 관계입니다.