Posted by Shawn Wilson on 03/01/06 20:56

CH4:D wrote:

> I usually just put a description on each table
> with the following things in its description: What it is, what data is
> stored (fields) and how is it stored (data types). Since you grow your
> database "organically" it would be a good idea to add to the
> description which tables reference it as well. If you're using linker
> or lookup table you can just describe the foreign keys there and where
> it goes.

I'm pretty good about commenting my code, but it never occurred to me to
comment in the db itself. That's a good idea.

> For diagramming, we use MS Visio or just Powerpoint will do. I suggest
> you research on symbols with entity relationships on tables. There's a
> standard set of symbols there. If your main purpose is merely for
> presentation, then you can just draw lines and arrows pointing to the
> table relationships since non-db folks won't care what these symbols
> are. They just want to see how the whole thing fits in.

I think I've got both of those kicking around here somewhere. I'll check
them out. I've been looking into the ERD symbols. We'll likely have 2 sets
of documents - technical (for me an in case potential investors ask for a
"technical audit") and overview.

> You don't need a good resource, it's just a matter of developing good
> practices. Your people will appreciate it in time as you learn to
> develop good documentation skills. It's not something you read but
> learn through experience. ;)

I like to go through written resources when I'm first learning things, then
adapt them to suit my needs. I find there's less reinvention of the wheel
that way.

Thanks for the reply,
Shawn

[Back to original message]