An ER diagram is the traditional formal way to document a database schema. There are a bunch of (expensive) commercial tools that will reverse-engineer your schema to an ER diagram, then allow you to modify the diagram, print pretty pictures and spit out DDL to create the schema for the database of your choice, which is a convenient way to support multiple target databases, by the way.
The best free tool I've run into for this task was Druid (druid.sourceforge.net). The GUI takes some getting used to, but it's pretty slick. Or at least it was 4 years ago, which is the last time I used it. Dia also has an ER diagram palette. -- Mark Lewis On Sun, 2007-03-18 at 10:24 -0700, Gus Wirth wrote: > I have a database that I want to document. Up till now I've just had my > own notes and the source code of the application to remind me of what > does what but I want to make it more formal than that. > > The database has about 50 tables, with a maximum of 25 fields per table; > most are much smaller. Right now I have some of the info in a > spreadsheet that has the table name, field name, field type, field size > (if required), description, and what programs use it. It also marks if a > field is a primary key or foreign key. This is probably good enough for > a small project. > > This sounds like it ought to be in database itself with a nice web front > end so I can browse and print. I can see using a small tool to > automatically get everything I need except the description. I could > probably just use the tools in the database to get all the meta > information (SQL) and massage that. Actually, I've done this because I > have the SQL CreateDatabase script that was done by reverse engineering > the existing database. Now to remember how I did it. > > Any recommendations on formally documenting database designs? > > Gus > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
