啊！明白了！有什么想法它会是什么样子吗？我们一直在寻找让这里变得更轻松的方法 
当然！像 Northwind（MS Access 的著名之处！）那样的数据模型将是极好的。甚至可能有一个工具可以通过检查 Postgres 模式来生成一个。
2 个赞
你能像跟新手说话一样分享一下吗？比如：
- 添加这个能帮助解决什么问题？
- 如果添加了，你期望看到它如何被使用？它会是什么样子？
我基本上是采纳你的建议，并询问更多细节（你能给多少就给多少 
），以便我们能为下一个接触到的数据架构师改善体验。我对数据没有背景，所以你的详细建议将很有帮助
2 个赞
哈哈 Osioke，
说得太对了！我认输……
所以，大多数从事数据库工作的人（不仅仅是数据架构师！开发人员也是！）都觉得有一个数据模型来展示各种表是如何相互连接的非常有帮助。
例如，以我的查询为例；），我需要关于某个用户的几条信息——我需要关于一个用户的以下信息：
- 是否（或不在）某个特定组中
- 已解决主题
- 在某个日期范围内
要回答上述问题，我需要用户表、用户操作表和组表。数据模型会告诉我，可以通过 id/user_id 将用户链接到用户操作，并通过 primary_group_id/id 直观地将用户链接到组。
这有助于可视化不仅可用的数据，还有如何连接它们，特别是当存在一些冗长的查询时。
是的，你可以点击数据浏览器中的每一个表来找出可用的字段，并记下来以免忘记，但对于我们中的一些人来说，拥有一个数据模型可能更人性化一些
5 个赞
啊！又明白了！
我不是技术人员，所以这对我来说不清楚。但我看到了需求，所以是的。数据模型会很有帮助。我来看看我能做什么。
在此期间，我已经将此对话移至我们在 Site feedback 类别中的新主题，以便保持其他讨论的清洁。
2 个赞
那太棒了，谢谢！
1 个赞
所以我和团队讨论了，这并非易事，原因有很多。我们也将其移至 Feature，因为它更能体现其功能。
目前，我们内部从事/使用数据的大多数人主要使用源代码中提供的模型：
我还看了 Northwind 数据模型：
这确实易于理解，可以打印在纸上或显示在一个屏幕上。总共 13 个表。
与 Discourse 相比，我们有更多的表，超过 180 个或更多，可视化这将是一次……漫长的旅程。特别是还有来自插件的表（这些表会因安装而异），以及 *_custom_fields 表中的数据，如果你真的想获得完整的图景，也应该包含在内。
另外，由于我们的数据库设计方式，我们无法使用大多数数据建模工具，我们需要找到一个适用于 ActiveRecord 模型的工具。而且我认为这也很棘手，所有这些关于数据对话的内容都超出了我的理解范围。
但这并不意味着我们不想做这件事，这只是我的看法。我很想听听你或其他人关于如何改进这件事的建议。
6 个赞
它确实没什么用，因为它的体积庞大，缺少外键，而且我们几乎没有将逻辑留给关系数据库管理系统 (RDMS)，这意味着不阅读 Discourse 源代码就很难理解 Discourse 数据库。
但如果你真的需要一个，RubyMine 可以为你生成它。
14 个赞
您可以使用 rails-erd 生成一个包含关系的图：GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications
不过，不确定这有多大用处。
10 个赞
@lju 我希望我们所有的解释都能有所帮助，特别是加上了额外的背景信息。我将在未来一两天内关闭此问题。如果你仍然觉得需要一些额外的细节，请随时提出。
3 个赞
1 个赞
太棒了！几天后你就会有了 感谢你对此的关注。
大家好：
所以我的观点是，数据模型会很有用，但我们不必包含所有表。我怀疑可能存在“关键”的 15-25 个左右的表，这些表占所有查询的 90%/人们正在寻找的内容。事实上，看看提供的各种表——可能会根据您想要探索的查询/数据的类型创建一系列数据模型。
在接下来的几天里，我可以尝试整理出我认为最常被查询的表——这不会是广泛的研究，只是一个初步的尝试。我相信在“数据探索器”类别中提出的各种问题也会揭示出热门的表。
还可以创建另一个图表来表示感兴趣的“区域”，以方便导航可用数据的不同部分。
这说得通吗？
祝好，
Lju
6 个赞
Data explorer 已经在查询编辑 UI 面板中将最重要的 9 个表列在最前面，您只需单击一下即可查看所有表的列结构和类型：
3 个赞
所以我们可以将这9个表变成一个简化的数据模型？ 
5 个赞
好的，请分享结果！
4 个赞
哇，这太大了；这是我见过的最大的数据库模式之一
这是用 https://dbdiagram.io 创建的吗？可以分享一下图表的公共网址吗？
我对这些表之间的关系和连接更感兴趣
users、
user_options、
api_keys、
user_api_keys、
user_auth_tokens、
user_auth_token_logs、
notifications
谢谢
非常有帮助，但如果能有一个可共享的 URL 就更好了，这样我们就可以看到表关系以及表上的主键/外键。
架构中是否存在一对一关系？我想知道，特别是 users 和 user_options 表之间的关系。
有人愿意根据模式图帮助我了解这些表之间的关系吗？
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
想知道是否存在一对一的关系。
将不胜感激……谢谢
主要是 1 对 N，因为用户有多个通知、身份验证令牌等。
user_options 是 1 对 1。