ああ！わかった！どのようなものになりそうか、何かアイデアはある？私たちは常に、ここでの作業をより簡単にする方法を探しているんだ 
「いいね！」 2
もちろんです！Northwind（MS Accessで有名！）のようなデータモデルがあれば素晴らしいでしょう。Postgresスキーマを調査して生成するツールさえあるかもしれません。
「いいね！」 2
初心者にもわかるように説明していただけますか？例えば：
- これを追加すると、どのような問題が解決されますか？
- 追加された場合、どのように見えると予想されますか？どのような見た目になりますか？
あなたの提案を基に、次のデータアーキテクトが利用できるように体験を向上させるために、さらに詳細（可能な限り ;)）を求めています。私はデータに関する知識がないため、詳細な提案は非常に役立ちます
「いいね！」 2
ハハ、オシオケさん、
まったくその通りです！参りました…
データベース（データアーキテクトだけでなく、開発者も！）を扱うほとんどの人が、さまざまなテーブルが互いにどのように接続されているかを示すデータモデルを持っていると非常に役立つと感じています。
たとえば、私のクエリを例にとりましょう 
ユーザーに関するいくつかの情報が必要でした。具体的には、以下の条件を満たすユーザーの情報が必要でした。
- 特定のグループに属している（または属していない）
- トピックを解決した
- 特定の期間内
上記に答えるには、usersテーブル、user_actionsテーブル、groupsテーブルが必要です。データモデルがあれば、ユーザーとユーザーアクションをid/user_id経由でリンクできること、そしてユーザーとグループをprimary_group_id/id経由で視覚的にリンクできることがわかります。
利用可能なデータだけでなく、特に複雑なクエリがある場合に、どのように結合するかを視覚化するのに役立ちます。
データエクスプローラーで個々のテーブルをクリックして、利用可能なフィールドを調べて書き留めておけば忘れないかもしれませんが、データモデルがあれば、私たちの一部にとってはもう少し人間的な方法になるかもしれません
「いいね！」 5
あ！また見つけちゃいました！
私は技術的なことは詳しくないので、これはよく分かりませんでした。ただ、必要性は理解できるので、はい。データモデルは確かに役立つものですね。私が何かできることを探してみます。
その間、この会話は Contribute > Site feedback カテゴリの新しいトピックに移動しました。他の議論を整理するためです。
「いいね！」 2
素晴らしいですね、ありがとうございます！
「いいね！」 1
なので、チームと議論したのですが、多くの理由からこれは straightforward（簡単）なことではありませんでした。そのため、Contribute > Feature に移動しました。これは、この取り組みが何を意味するかがより明確に示されるからです。
現在、私たちが社内データに関連する作業をしているメンバーは、主にソースコード内で利用可能なモデルを使用しています：
また、Northwind データモデルも確認しました：
これは確かに理解しやすく、紙や1画面に収まるサイズです。合計で13のテーブルです。
これを Discourse と比較すると、Discourse には180以上のテーブルがあり、これを可視化するのは…大変な旅になります。特に、プラグイン由来のテーブル（インストールごとに異なります）や、完全な像を把握したい場合は含めるべき *_custom_fields テーブル内のデータがあるためです。
さらに、データベースの設計方法により、データモデリング用のツールの多くを使用することができません。ActiveRecord モデルと連携するものを見つける必要があります。これもまた複雑な要因の一つであり、これらすべてのデータに関する議論は私の理解を超えています。
ただし、これがやりたいことではないという意味ではありません。これは単なるコメントです。これをより良くするための提案や、他の誰かからのアイデアをお待ちしています。
「いいね！」 6
それはあまり役に立ちません。その巨大さ、外部キーの欠如、そしてRDMSにほとんどロジックを残していないため、Discourseのソースを読まずにDiscourse DBを理解するのは困難です。
しかし、どうしても必要な場合は、RubyMineが生成してくれます。
「いいね！」 14
rails-erd を使用して生成できます: GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications
ただし、どれほど役立つかはわかりません。
「いいね！」 10
@lju ここでの説明が、特に追加されたコンテキストとともに、すべて役立つことを願っています。1、2日中にこれをクローズします。まだ追加の詳細が必要だと感じている場合は、遠慮なくお尋ねください。
「いいね！」 3
@osioke様
返信が遅くなり申し訳ありません。少し立て込んでおりました。
いくつか役立ちそうなアイデアがあります。数日いただければ、まとめてみます。
よろしくお願いいたします。
Lju
「いいね！」 1
素晴らしい！数日中に ご注目いただきありがとうございます。
皆さん、こんにちは。
データモデルは役立つと思いますが、必ずしもすべてのテーブルを含める必要はないというのが私の意見です。おそらく、すべてのクエリの90％で使用されている、または人々が探している「主要な」15〜25個程度のテーブルがあると思われます。実際、利用可能なさまざまなテーブルを見ると、探しているクエリ/データの種類に基づいて、いくつかのデータモデルを作成できる可能性があります。
今後数日間で、最も一般的にクエリされると思われるテーブルをまとめることができます。これは広範な調査ではなく、推測にすぎません。「Data Explorer」カテゴリで尋ねられたさまざまな質問も、人気のあるテーブルを明らかにすることでしょう。
また、「ゾーン」を表す別の図を作成して、利用可能なさまざまなデータ部分のナビゲーションを容易にすることもできます。
これで意味が通じますか？
よろしく、
Lju
「いいね！」 6
データエクスプローラーには、クエリ編集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対多です。
user_options は1対1です。