From: Peter Brawley
Date: September 26 2005 4:11am
Subject: Re: Documenting and visualizing a database
List-Archive: http://lists.mysql.com/mysql/189538
Message-Id: <433774E3.6000300@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jeffrey,

 >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.

There are quite a few db design tools that can write data models from 
MySQL databases, but for various reasons, more run on Windows than on 
*nix. One of our favourites is Dezign from Datanamic; inexpensive and 
good. If you have access to a Windows box, it might be worth your while 
to do the reverse engineering there, using one of those tools.

One tool that can produce a UML model from a MySQL db under *nix is DB 
Visual Architect, but it's pricey. MySQL AB recently purchased such a 
tool, DB Designer, rechristened it MySQL Workbench, & just released an 
alpha version for Windows.

PB
http://www.artfulsoftware.com

-----


Jeffrey Goldberg wrote:

>
> 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
>
>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 9/23/2005