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
