Nella mia esperienza, i diagrammi ER (o UML) non sono l'artefatto più utile:con un gran numero di tabelle, i diagrammi (soprattutto quelli di reverse engineering) sono spesso un grande pasticcio contorto da cui nessuno impara nulla.
Per i miei soldi, una buona documentazione leggibile dall'uomo (forse integrata con diagrammi di porzioni più piccole del sistema) ti darà il massimo del chilometraggio. Ciò includerà, per ogni tabella:
- Descrizioni del significato della tabella e di come viene utilizzata funzionalmente (nell'interfaccia utente, ecc.)
- Descrizioni del significato di ciascun attributo, se non è ovvio
- Spiegazioni delle relazioni (chiavi esterne) da questa tabella ad altre e viceversa
- Spiegazioni di ulteriori vincoli e/o trigger
- Spiegazione aggiuntiva delle principali viste e processi che toccano il tavolo, se non sono già ben documentati
Con tutto quanto sopra, non documentare per il bene di documentare:la documentazione che ribadisce l'ovvio ostacola le persone. Invece, concentrati sulle cose che ti hanno confuso all'inizio e dedica qualche minuto a scrivere spiegazioni molto chiare e concise. Questo ti aiuterà a pensarci bene e sarà massicciamente aiuta altri sviluppatori che si imbattono in queste tabelle per la prima volta.
Come altri hanno già detto, esiste un'ampia varietà di strumenti per aiutarti a gestirlo, come Enterprise Architect, Red Gate SQL Doc e gli strumenti integrati di vari fornitori. Ma mentre il supporto degli strumenti è utile (e anche critico, in database più grandi), fare il duro lavoro di comprendere e spiegare il modello concettuale del database è la vera vittoria. Da quel punto di vista, puoi persino farlo in un file di testo (sebbene farlo in forma Wiki consentirebbe a più persone di collaborare per aggiungere a quella documentazione in modo incrementale, quindi, ogni volta che qualcuno scopre qualcosa, può aggiungerlo al corpo in crescita di documentazione istantaneamente).
