ああ！わかった！どのようなものになりそうか、何かアイデアはある？私たちは常に、ここでの作業をより簡単にする方法を探しているんだ 
「いいね！」 2
もちろんです！Northwind（MS Accessで有名！）のようなデータモデルがあれば素晴らしいでしょう。Postgresスキーマを調査して生成するツールさえあるかもしれません。
「いいね！」 2
初心者にもわかるように説明していただけますか？例えば：
- これを追加すると、どのような問題が解決されますか？
- 追加された場合、どのように見えると予想されますか？どのような見た目になりますか？
あなたの提案を基に、次のデータアーキテクトが利用できるように体験を向上させるために、さらに詳細（可能な限り ;)）を求めています。私はデータに関する知識がないため、詳細な提案は非常に役立ちます
「いいね！」 2
ハハ、オシオケさん、
まったくその通りです！参りました…
データベース（データアーキテクトだけでなく、開発者も！）を扱うほとんどの人が、さまざまなテーブルが互いにどのように接続されているかを示すデータモデルを持っていると非常に役立つと感じています。
たとえば、私のクエリを例にとりましょう 
ユーザーに関するいくつかの情報が必要でした。具体的には、以下の条件を満たすユーザーの情報が必要でした。
- 特定のグループに属している（または属していない）
- トピックを解決した
- 特定の期間内
上記に答えるには、usersテーブル、user_actionsテーブル、groupsテーブルが必要です。データモデルがあれば、ユーザーとユーザーアクションをid/user_id経由でリンクできること、そしてユーザーとグループをprimary_group_id/id経由で視覚的にリンクできることがわかります。
利用可能なデータだけでなく、特に複雑なクエリがある場合に、どのように結合するかを視覚化するのに役立ちます。
データエクスプローラーで個々のテーブルをクリックして、利用可能なフィールドを調べて書き留めておけば忘れないかもしれませんが、データモデルがあれば、私たちの一部にとってはもう少し人間的な方法になるかもしれません
「いいね！」 5
ああ！またやられました！
私は技術者ではないので、これは私には明確ではありませんでした。しかし、必要性は理解していますので、はい。データモデルは役立つものになるでしょう。何ができるか見てみますね。
それまでの間、他の議論をきれいに保つために、この会話を#site-feedbackカテゴリの新しいトピックに移動しました。
「いいね！」 2
素晴らしいですね、ありがとうございます！
「いいね！」 1
チームと話していたのですが、これは多くの理由から簡単なことではありません。また、これが何であるかをよりよく示すために、Feature に移動しました。
現在、社内でデータを扱っている者たちは、主にソースコードで利用可能なモデルを使用しています。
Northwind のデータモデルも確認しました。
これは確かに理解しやすく、紙や 1 つの画面に収まるサイズです。全部で 13 のテーブルがあります。
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です。