Comment documentez-vous le code de votre base de données pour voir les dépendances entre les objets de base de données?

Question

Je veux écrire de la documentation sur mon projet favori.

J'ai 30 tables et près de 50 vues et environ 30 fonctions (procédures stockées) dans ma base de données PostgreSQL.

Je voudrais voir où les tables (quelles vues et quelles fonctions) sont utilisées.

Je voudrais voir où les vues (quelles vues et quelles fonctions) sont utilisées.

Je voudrais voir si une fonction est utilisée par une autre fonction.

Je voudrais aussi écrire une description de chaque objet (tables, vues et fonctions)

et une brève description des champs.

Peu de temps, je veux être en mesure de voir ce que l'utilisation d'un objet spécifique et quels objets utilisent un objet spécifique. Je pensais utiliser un fichier texte et pour chaque objet. Je pourrais lister les objets qui utilisent le courant et ceux qui sont utilisés par le courant.

<pre> 
Table aaaa 
A short description 
used by : view v_aaaa 

id int  primary key 
name varchar(30) name of a... 

================================ 
view v_aaaa 
A short description 

list of fields... 

used by function f_aaaa 
Depends on table aaaa 



============================== 

function f_aaaa 
A short description 
Parameters (description, IN/OUT) 
Depends on view v_aaaa 
      function fbbbb 

============================== 

function f_bbbb 
A short description 
Parameters 
Called by function f_aaaa 

Je crains que ma documentation sera Désynchroniser rapidement Imaginer ajouter une f_cccc fonction qui appelle f_aaaa et f_bbbb. Je vais devoir modifier doc sur f_aaaa et f_bbbb

Je sais que UML décrit les relations à propos des entités (c'est le cas, non?). Mais je veux quelque chose de simple et je ne veux pas suivre une formation de 75 heures ... Et je ne suis pas sûr que vous puissiez avoir un "lien" entre les entités et la fonction que je veux.

Avez-vous quelque chose à me suggérer? J'utilise PostgreSQL sous Linux (Fedora). Si vous proposez un outil qui le fait, il doit être compatible avec PostgreSQL :-)

Pour ma documentation de code, j'utilise Doxygen.

Merci

Answer 1

je construis enfin un énorme fichier HMTL.

Le fichier contient beaucoup d'ancres et il est facile de naviguer vers différents objets.

Il est beaucoup de travail, mais il était exactement ce que je veux :-)

Answer 2

Dessinez simplement un diagramme EAR. Diagramme Entité-Relation.

Ce tutoriel devrait vous donner une bonne compréhension. http://www.scribd.com/doc/7500847/entity-relationship-diagram

Et vous avez celui http://www.getahead-direct.com/gwentrel.htm

Edit:

Disons que vous avez une voiture de Tabe, vous dessinez une boîte VOITURE:

CAR 
---------- 
id (int) 
name (vchar) 
numbSeats (int) 
---------- 
GetCar 
SetCar 
DeleteCar 

LADERNI 3 sont vos fonctions.

Answer 3

Je ne documente pas afin de voir les dépendances. La documentation est automatiquement périmée.

J'utilise un outil pour cela. Actuellement, j'utilise les produits de ApexSQL, mais j'ai utilisé les outils Redgate dans le passé.

Answer 4

Vous pouvez réellement collecter certaines de ces informations en interrogeant les informations internes de la base de données. Si quelque chose dépend d'un autre, cela suggère qu'il l'utilise. Voici une exemple de requête pour vous donner une idée de traverser les deux structures impliquées:

SELECT 
    c1.oid as relid, 
    n1.nspname || '.' || c1.relname as relation, 
    c1.relkind, 
    c2.oid as relid, 
    n2.nspname || '.' || c2.relname as dependency, 
    c2.relkind 
FROM 
    pg_depend d, 
    pg_class c1, 
    pg_namespace n1, 
    pg_class c2, 
    pg_namespace n2 
WHERE 
    d.objid = c1.oid AND 
    c1.relnamespace = n1.oid AND 
    n1.nspname NOT IN('information_schema', 'pg_catalog') AND 
    n1.nspname !~ '^pg_toast' AND 
    d.refobjid = c2.oid AND 
    c2.relnamespace = n2.oid AND 
    n2.nspname NOT IN('information_schema', 'pg_catalog') AND 
    n2.nspname !~ '^pg_toast' AND 
    c1.oid != c2.oid 
GROUP BY n1.nspname,c1.relname,c1.oid,c1.relkind, 
    n2.nspname,c2.relname,c2.oid,c2.relkind 
ORDER BY n1.nspname,c1.relname; 

Informations sur tous ces bits internes peuvent être trouvés dans la documentation system catalog.

Answer 5

envisager d'utiliser une convention de nommage pour renforcer les dépendances d'objets SQL:

Table1

Tableau 2

vw_table1_byField1

vw_table1_byField1_table2

vw_table2

fn_tabl e1

fn_table1_table2