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 comprends mieux ! 
Je ne suis pas technique, donc ce n’était pas clair pour moi. Je vois bien l’utilité par contre, donc oui. Un modèle de données serait effectivement utile. Laissez-moi voir ce que je peux faire.
En attendant, j’ai déplacé cette conversation vers un nouveau sujet dans notre catégorie Contribute > Site feedback, afin de garder les autres discussions propres.
2 « J'aime »
Ce serait formidable, merci !
1 « J'aime »
Je discute donc avec l’équipe et il s’avère que ce n’est pas une tâche simple pour de nombreuses raisons. Nous avons également déplacé cette discussion vers Contribute > Feature, car cela illustre mieux la nature de ce projet.
Actuellement, ceux d’entre nous qui travaillent avec les données en interne utilisent principalement les modèles disponibles dans le code source :
J’ai également jeté un œil au modèle de données Northwind :
C’est clairement facile à comprendre et à représenter sur une feuille de papier ou un seul écran. Il y a 13 tables au total.
En comparant cela à Discourse, nous avons beaucoup plus de tables, plus de 180, voire davantage. Visualiser cela serait… une véritable aventure. Surtout qu’il y a aussi des tables provenant de plugins (et celles-ci changent d’une installation à l’autre) ainsi que des données dans les tables *_custom_fields qui devraient également être incluses si vous souhaitez vraiment avoir une vue d’ensemble 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 compatible avec les modèles ActiveRecord. Et je pense que cela rend aussi la tâche plus délicate. Toutes ces conversations techniques dépassent largement mes compétences.
Cela dit, cela ne veut pas dire que nous ne voulons pas le faire, c’est juste un commentaire. J’aimerais beaucoup entendre vos suggestions ou celles de toute autre personne sur les façons 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.