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
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
