J'ai récemment été embauché en tant que seul informaticien dans une certaine société X et je suis chargé de corriger leurs applications, et à mon avis, la meilleure façon de commencer est de comprendre la base de données.
Leur base de données actuelle est une base de données MySQL avec 186 tables (notez que certaines tables sont vides car Dieu sait pourquoi). Et l'application communique avec la base de données via une interface de base de données MS Access. (Je me demande pourquoi les développeurs ont fait ça aussi)
La question est, comment puis-je commencer à lutter contre cette grande base de données non documentée? Oui, ce n'est pas documenté car les développeurs de l'application ne sont pas disposés à me donner un ERD ou un dictionnaire de données ou toute information sur la base de données pour me faciliter la vie. Comment proposeriez-vous d'entreprendre cet effort périlleux de comprendre tous les coins et recoins de la base de données plutôt volumineuse?
Question connexe: comment plonger dans une base de données laide?
Réponses:
La réponse liée aborde le problème de bas en haut, la base de données d'abord. Comme vos responsabilités englobent les applications et la base de données, je serais enclin à attaquer cette approche descendante à partir de la ou des applications.
Concentrez votre attention sur la compréhension des fonctionnalités les plus fréquemment utilisées de l'application en consultant la base d'utilisateurs. Suivez les interactions de la base de données de ces fonctionnalités à l'aide d'outils de profilage / journalisation afin d'identifier les tables et procédures clés.
De cette façon, vos premiers efforts sont limités à la «substance qui compte», plutôt que de perdre du temps à documenter des tables et des requêtes qui peuvent être rarement ou jamais utilisées. L'accent devrait également mettre le principe de Pareto à nu sur vos efforts de correction de bogues ( comme le dit Microsoft de toute façon ).
la source
J'essaierais peut-être d'obtenir MySQL Workbench puis de créer un modèle EER à partir de la base de données. Cela signifie que vous pouvez voir ce qui relie à quoi et savoir ce que les développeurs pourraient penser. Tout dépend également de la façon dont elle est structurée.
la source
Je trouve que DBLint est utile pour l'identification des problèmes avec la base de données. Il a les belles propriétés suivantes:
Pour une identification rapide des hotspots sur la base de données MySQL, Neor Profile SQL est un proxy pratique qui se situe entre l'application et la base de données. La beauté de celui-ci est qu'il est rapide à installer.
Pour la découverte des clés factuelles primaires et étrangères dans la base de données, qui ne sont néanmoins pas définies dans la base de données, vous pouvez utiliser Linkifier . Pour le tracé ERD, les estimations peuvent être exportées dans yEd , qui possède de nombreux algorithmes de disposition pour le positionnement des tableaux. BPMN est mon préféré pour les ERD.
la source
Il existe un outil d'oracle (My SQl workbench) pour accéder à la base de données My Sql, c'est une interface qui pourrait vous donner l'ERD de la base de données.
la source