Ah ! Je vois ! Des idées sur ce à quoi cela pourrait ressembler ? Nous cherchons toujours des moyens de faciliter les choses ici 
2 « J'aime »
Bien sûr ! Quelque chose comme le modèle de données Northwind (célèbre sur MS Access !) serait génial. Il existe peut-être même un outil qui en générera un en analysant le schéma Postgres.
2 « J'aime »
Pouvez-vous partager cela comme si vous parliez à un débutant ? Par exemple :
- Qu’est-ce que l’ajout de ceci aiderait à résoudre ?
- Comment vous attendriez-vous à voir cela s’il est ajouté ? À quoi cela ressemblerait-il ?
J’adopte essentiellement votre suggestion et je demande plus de détails (autant que vous pouvez en donner 
) afin que nous puissions améliorer l’expérience pour le prochain architecte de données qui se présentera. Je n’ai aucune expérience en données, donc votre suggestion détaillée sera utile
2 « J'aime »
Haha Osioke,
Très juste ! Bien joué…
La plupart des personnes qui travaillent avec des bases de données (pas seulement les architectes de données ! Les développeurs aussi !) trouvent très utile d’avoir une sorte de modèle de données qui leur montre comment les différentes tables sont connectées les unes aux autres.
Par exemple, prenons ma requête ;), j’avais besoin de plusieurs informations sur un utilisateur - j’avais besoin d’informations sur un utilisateur qui :
- était (ou n’était pas) dans un groupe particulier
- avait résolu un sujet
- dans une certaine plage de dates
Pour répondre à ce qui précède, j’ai besoin de la table des utilisateurs, de la table des actions des utilisateurs et de la table des groupes. Un modèle de données m’aurait montré que je peux lier un utilisateur à une action utilisateur via id/user_id, et lier un utilisateur à un groupe via leur primary_group_id/id visuellement.
Cela aide à visualiser non seulement quelles données sont disponibles, mais comment les joindre, surtout s’il y a des requêtes un peu longues en jeu.
Oui, vous pourriez cliquer sur chaque table dans l’explorateur de données pour découvrir quels champs sont disponibles et les noter afin de ne pas les oublier, mais avoir un modèle de données peut être un peu plus humain pour certains d’entre nous
5 « J'aime »
Ah ! Je vous ai eu ! 
Je ne suis pas technique, donc cela n’était pas clair pour moi. Je vois le besoin cependant, donc oui. Un modèle de données serait utile. Voyons ce que je peux faire.
En attendant, j’ai déplacé cette conversation vers un nouveau sujet dans notre catégorie Site feedback afin de garder l’autre discussion propre.
2 « J'aime »
Ce serait formidable, merci !
1 « J'aime »
Je discute avec l’équipe et ce n’est pas quelque chose qui serait simple pour de nombreuses raisons. Nous l’avons également déplacé vers Feature car cela montre davantage ce que cela impliquerait.
Actuellement, ceux d’entre nous qui travaillent sur/avec des données en interne utilisent principalement les modèles disponibles dans le code source :
J’ai également jeté un coup d’œil au modèle de données Northwind :
C’est certainement facile à comprendre et tient sur une feuille de papier ou un écran. 13 tables au total.
En comparant cela à Discourse, nous avons beaucoup plus de tables, plus de 180 ou plus, visualiser cela serait… un voyage. Surtout parce qu’il y a aussi des tables provenant de plugins (et celles-ci changent d’une installation à l’autre) et des données dans les tables *_custom_fields qui devraient également être incluses si vous voulez vraiment avoir une image complète.
De plus, en raison de la conception de notre base de données, nous ne pouvons pas utiliser la plupart des outils de modélisation de données, nous devrions en trouver un qui fonctionne avec les modèles ActiveRecord. Et je pense que cela rend aussi les choses délicates, toutes ces conversations sur les données sont au-delà de mes compétences.
Mais cela ne veut pas dire que ce n’est pas quelque chose que nous ne voulons pas faire, ce ne sont que des commentaires. J’aimerais beaucoup entendre vos suggestions ou celles de quiconque sur la façon dont nous pourrions améliorer cela.
6 « J'aime »
Ce n’est pas très utile, car sa taille immense, l’absence de clés étrangères et le fait que nous laissions très peu de logique au SGBDR rendent difficile la compréhension de la base de données Discourse sans lire le code source de Discourse.
Mais si vous en avez vraiment besoin, RubyMine peut le générer pour vous.
14 « J'aime »
Vous pouvez en générer un avec des relations avec rails-erd : GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications
Je ne suis pas sûr de l’utilité de ceci cependant.
10 « J'aime »
@lju J’espère que toutes nos explications vous aideront ici, surtout avec le contexte ajouté. Je vais clore ceci dans un jour ou deux. Si vous pensez avoir encore besoin de détails supplémentaires, n’hésitez pas à demander.
3 « J'aime »
Salut @osioke ,
Désolé pour le retard dans ma réponse, j’ai été un peu débordé.
J’ai quelques idées sur ce qui pourrait être utile - si vous pouvez me donner quelques jours, je rédigerai quelque chose.
Cordialement,
Lju
1 « J'aime »
Génial ! Vous avez quelques jours maintenant merci de l’attention portée à cela.
Salut à tous,
Mon argument serait donc qu’un modèle de données serait utile, mais que nous n’avons pas nécessairement besoin d’inclure toutes les tables. Je soupçonne qu’il y a probablement les 15-25 tables « clés » que 90 % de toutes les requêtes utilisent/que les gens recherchent. En fait, en examinant les différentes tables disponibles, il est probable que plusieurs modèles de données puissent être créés, en fonction des types de requêtes/données que vous cherchez à explorer.
Je peux essayer dans les prochains jours de rassembler ce que je pense être les tables les plus fréquemment interrogées - ce ne serait pas une recherche exhaustive, juste une supposition. Je suis sûr que les diverses questions posées dans la catégorie Data Explorer mettront également en lumière les tables populaires.
Il pourrait également y avoir un autre diagramme pour représenter les « zones » d’intérêt afin de faciliter la navigation dans les différentes parties des données disponibles.
Est-ce que cela a du sens ?
Cordialement,
Lju
6 « J'aime »
L’explorateur de données liste déjà les 9 tables les plus importantes en premier dans le panneau de l’interface utilisateur d’édition des requêtes, et vous pouvez voir la structure et les types de colonnes de toutes les tables en un clic :
3 « J'aime »
Alors nous pourrions prendre ces 9 tables et les transformer en un modèle de données simplifié ? 
5 « J'aime »
Bien sûr, partagez les résultats !
4 « J'aime »
C’est énorme ; l’un des plus grands schémas de base de données que j’ai vu en ligne.
A-t-il été créé avec https://dbdiagram.io ? Pouvez-vous partager l’URL publique du diagramme ?
Je suis plus intéressé par les relations et les connexions entre ces tables :
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
Merci.
très utile mais ce serait bien d’avoir une URL partageable pour que nous puissions voir les relations entre les tables et aussi les clés primaires/étrangères sur les tables
y a-t-il des relations 1-à-1 dans le schéma ? j’aimerais savoir surtout entre les tables users et user_options
quelqu’un est-il prêt à aider avec les relations entre ces tables ? à partir du schéma diagramme
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
intéressé de savoir s’il existe des relations 1-à-1
j’apprécierais.. merci
C’est principalement 1-N, car les utilisateurs ont plusieurs notifications, jetons d’authentification, etc.
user_options est 1-1.