• # Et pour les très grosses bases...

    Posté par . En réponse au journal Graph my database. Évalué à 8.

    Le problème qu'on avait ici, c'était qu'on a des vieilles applications qui n'ont pas 20 ou 30 tables, mais plutôt 200 ou 300 (voire plus). Et que beaucoup d'entre elles n'ont pas de contraintes d'intégrité.

    Et c'est surtout celles là qu'on veut documenter, car quand on arrive sur un tel projet, c'est l'enfer pour comprendre le modèle.

    Au final, on ne peut donc pas s'appuyer directement sur un outil qui extrait les metadatas ; et on ne peut pas tout représenter sur un seul graphe - ça n'aurait aucun sens et n'apporterait aucune aide.

    Donc il faut toujours une étape manuelle de manipulation du résultat pour le splitter deux catégories de graphes :

    1) les graphes par domaine fonctionnel ; où tu montres même parfois seulement les tables principales, ou alors tu ne détaille que les tables principales - pour les autres tu ne montre que les attributs de clé primaire voire quelques attributs sélectionnés par un être humain.

    2) les graphes globaux ; où tu représente très grossièrement chaque domaine fonctionnel et tu mets en exergue les tables qui sont transverses et importantes.

    Autrement dit, tu utilises un outil de génération pour le début du travail, mais après c'est tout à la mimine. Et souvent, tu vas te retrouver à maintenir totalement à la main... Avant je faisais ça avec des gros outils propriétaires (PowerDesigner), mais ça finit toujours par être abandonné.

    Encore autrement dit : à ce jour je n'ai pas trouvé de bonne solution. Le taux de travail manuel était pour moi un bon indicateur de "quelle quantité de travail est nécessaire pour remettre cette base d'applomb"...