On Sun, March 18, 2007 10:24 am, 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 >
Which DB are you using? Postgres has a couple of things that might help you. 1. pgaccess is a Tcl/Tk graphic fromt end to a Postgres data base that allows pretty good visualization and editing of tables. I do most of my DB development in it, then have PG write out the SQL to regenerate things. 2. WyattERP (http://www.wyatterp.com/index.html) has a couple of utilities for developing, editing, and keeping track of complex schemas. NB: I haven't had time to delve into these, which is one reason I'm trying to negotiate a webinar with the WyattERP developer for April's sdtug meeting on 4/19/07. HTH, -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
