List:General Discussion« Previous MessageNext Message »
From:Jeffrey Goldberg Date:September 26 2005 3:39am
Subject:Re: Documenting and visualizing a database
View as plain text  
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

Thread
Documenting and visualizing a databaseJeffrey Goldberg26 Sep
  • Re: Documenting and visualizing a databaseRobert L Cochran26 Sep
    • Re: Documenting and visualizing a databaseJeffrey Goldberg26 Sep
      • Re: Documenting and visualizing a databasePeter Brawley26 Sep
        • Re: Documenting and visualizing a databaseDaniel Kasak26 Sep
          • Re: Documenting and visualizing a databaseRaz26 Sep
            • Re: Documenting and visualizing a databaseDaniel Kasak27 Sep
              • Re: Documenting and visualizing a databaseRaz27 Sep
          • Re: Documenting and visualizing a databaseRaz26 Sep
            • Re: Documenting and visualizing a databaseGraham Reeds4 Oct
          • Re: Documenting and visualizing a databasePeter Brawley26 Sep
  • Re: Documenting and visualizing a databaseolinux3 Oct
    • Re: Documenting and visualizing a databaseLigaya Turmelle3 Oct
      • Re: Documenting and visualizing a databaseKevin Liu3 Oct
        • Re: Documenting and visualizing a databaseEdward Vermillion4 Oct