On Sep 25, 2005, at 5:44 PM, Robert L Cochran wrote:
> I would start by writing down what you believe the database
> consists of:
>
> 1. The table structures -- write them down, commit them to paper.
Thanks, I've already printed out all of table structure information.
> 2. The relationships you believe exist between the tables. Document
> them in writing and visually.
That is what I have started to do. Because the stuff that I was
writing down seemed, well, fairly structured, I'd assumed that there
were some useful conventions for recording these.
> Use whatever tool works for now -- don't make the mistake of
> allowing the tools to stand in the way of proper documentation.
Of course. But I was hoping that existing tools might remind me to
note down things that I might not have occurred to me to note down.
> Now look at the code components.
>
> 1. Print and organize all the code that exists.
> 2. Study the code; determine how each component relates to the
> others. Diagram this program flow as above for the tables. Don't
> let lack of software stop you. Pen and paper is better than exactly
> nothing.
I wasn't looking for software for this part, though something like
ctags for PHP would be nice. After printing everything out, the next
thing I did was put things under revision control.
> As to learning MySQL and PHP, there is really only one good
> technical writer for MySQL: Paul DuBois. His book MySQL 3rd edition
> is a must-read.
Thanks.
> But even Paul is not a magician; you can't learn MySQL from a book
> alone. You need Paul's book, and the willingness to practice
> working with MySQL.
Of course. The Tutorial from MySQL AB requires that. And I've
successfully added some new required things to the project.
> Of the various PHP writers, I really have great respect for Tim
> Converse and Joyce Parks.
Again, thanks for the recommendation.
But I'm still left puzzled. If people haven't developed tailored
tools to document a database, then I find more than a bit of irony in
the fact that people who specialize in organizing data in useful ways
would not have developed a way to organize data that they need to
make use of on a daily basis.
Cheers,
-j
