А, понял! Есть какие-то идеи, как это может выглядеть? Мы всегда ищем способы сделать это проще здесь 
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:
Она действительно проста для понимания и помещается на листе бумаги или одном экране. Всего 13 таблиц.
Если сравнить это с Discourse, у нас гораздо больше таблиц — более 180, и визуализация этого была бы… настоящим путешествием. Особенно потому, что есть ещё таблицы из плагинов (которые меняются от установки к установке), а также данные в таблицах *_custom_fields, которые тоже нужно включить, если вы хотите получить полную картину.
Кроме того, из-за того, как устроена наша база данных, мы не можем использовать большинство инструментов для моделирования данных — нам нужно найти такой, который работает с моделями ActiveRecord. И я думаю, что это тоже усложняет задачу, ведь все эти разговоры о данных немного выше моей головы.
Но это не значит, что мы не хотим этого делать — это просто комментарий. Мне бы очень хотелось услышать ваши или чьи-либо ещё предложения о том, как мы могли бы улучшить ситуацию. 
6 лайков
Это действительно не так полезно: из-за его огромного размера, отсутствия внешних ключей и того, что мы оставляем очень мало логики в СУБД, сложно понять структуру базы данных Discourse без чтения исходного кода Discourse.
Но если вам действительно нужен такой документ, RubyMine может сгенерировать его для вас.
14 лайков
Вы можете сгенерировать её с помощью rails-erd: GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications · GitHub
Хотя не уверен, насколько это полезно.
10 лайков
@lju Надеюсь, все наши объяснения здесь были полезны, особенно с добавлением контекста. Я закрою эту тему в ближайшие один-два дня. Если вам всё же понадобятся дополнительные подробности, не стесняйтесь спрашивать.
3 лайка
Привет, @osioke,
Извини за задержку с ответом, я был немного завален делами.
У меня есть несколько идей, что могло бы быть полезным. Если ты дашь мне пару дней, я всё опишу.
С наилучшими пожеланиями,
Lju
1 лайк
Отлично! Через несколько дней у вас будет спасибо, что уделили этому внимание.
Всем привет,
Так вот, мой аргумент заключается в том, что модель данных была бы полезна, но нам не обязательно включать все таблицы. Я подозреваю, что, вероятно, существует около 15–25 ключевых таблиц, которые используются в 90 % всех запросов или которые интересуют людей. Фактически, глядя на различные доступные таблицы, можно предположить, что можно создать несколько моделей данных в зависимости от типов запросов или данных, которые вы хотите исследовать.
В ближайшие несколько дней я могу попытаться собрать то, что, по моему мнению, будет наиболее часто запрашиваемыми таблицами. Это не будет глубоким исследованием, скорее, предположение наугад. Уверен, что различные вопросы, задаваемые в категории «Data Explorer», также прольют свет на популярные таблицы.
Также можно создать ещё одну схему для обозначения «зон» интереса, чтобы облегчить навигацию по различным частям доступных данных.
Имеет ли это смысл?
С уважением,
Лью
6 лайков
В Data Explorer в панели редактирования запроса уже сначала перечислены 9 наиболее важных таблиц, и по одному клику можно увидеть структуру и типы столбцов всех таблиц:
3 лайка
Так что мы могли бы взять эти 9 таблиц и преобразовать их в упрощённую модель данных? 
5 лайков
Конечно, делитесь результатами!
4 лайка
Черт, это огромная схема — одна из самых больших, которые я видел в интернете.
Она создана с помощью https://dbdiagram.io? Не могли бы вы поделиться публичной ссылкой на диаграмму?
Меня больше интересуют связи и отношения между этими таблицами:
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
Спасибо.
Очень полезно, но было бы здорово иметь возможность получить ссылку для общего доступа, чтобы мы могли видеть связи между таблицами, а также первичные и внешние ключи в таблицах.
Есть ли в схеме связи один-к-одному? Хотелось бы узнать, особенно между таблицами users и user_options.
Кто-нибудь готов помочь разобраться с связями между этими таблицами? Исходя из схемы:
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
Хотелось бы узнать, есть ли здесь связи один-к-одному.
Буду признателен за помощь.. спасибо
В основном это отношения «один ко многим», так как у пользователей есть несколько уведомлений, токенов аутентификации и т. д.
user_options — это отношение «один к одному».