documentation

hello everyone,
I have to document about four databases, has anyone got any specific format or tool for documenting a database?
Any inputs would be very helpful
regards,
Harshal.I've used this tool (http://www.sql-server-performance.com/total_sql_analyzer.asp) earlier.|||Originally posted by Satya
I've used this tool (http://www.sql-server-performance.com/total_sql_analyzer.asp) earlier.

thanks for the quick reply,
but I have to write in details about the use of the table and the logic used in the stored procs also.
I'll go thru the software, is there any specific format for documenting?

Regards,
Harshal.|||I think with the help of VISIO also you can accomplish the task.
As of I know there is no specific format as such, it depends how easy you document.|||Originally posted by Satya
As of I know there is no specific format as such, it depends how easy you document.

yeah i guess it is so.

but really, documentation is third grade torture. :mad:|||Shame is no compatible tools available to document the database, rather we should depend upon third party supplied tools.:o|||Originally posted by Satya
Shame is no compatible tools available to document the database, rather we should depend upon third party supplied tools.:o

I beg to god for an :D intellegent tool :D which would also document all my procedures and their logic :D|||You will have to wait for next version of SQL Server after Yukon .. they might add it by then :)|||Documentation, is documentation.

It is painful.

If the code's not clean, it's even more painful.

Sorry...been there, done that.

PROC NAME:

Purpose:

Inputs:

Outputs:

Process flow:

And that's just the sprocs...

Do you need to a data model as well?

What about an application process model?

And what did you do wrong to get this assignment?|||documentation is already there, basic, maybe even primitive, but is there, in diagrams. if one was too lazy to write it as the app was being developed, doing it when everything else is done is going to be a project in itself. when this is the situation, you can use something as simple as copy con from dos prompt, or as sophisticated as robohelp office or er/studio or visio. the tool does not make any difference for as long as features of the tool will adequately describe what you got.|||Originally posted by Brett Kaiser
Documentation, is documentation.

It is painful.

If the code's not clean, it's even more painful.

Sorry...been there, done that.

PROC NAME:

Purpose:

Inputs:

Outputs:

Process flow:

And that's just the sprocs...

Do you need to a data model as well?

What about an application process model?

And what did you do wrong to get this assignment?

:rolleyes:

yeah the format is jsut similar to what i am currently using.
The real thing is in the process flow:mad: at places the code is worst this part is driving me crazy.
The application process model is to be documented by another guy :D
but yeah i do have to have the data flow diagrams :(

what i do wrong?
well that is a question i am been thinking of since yesterday
:D :p|||Well, in all honesty, walking in to a piece of sh-t system with no dco, is what a hired gun is all about.

If you can figure the sh-t out, you can do anything.

And yes, I always start with a data flow digram...

Gives a very clear picture of what's going on...

It's a higher level, but it gives you everything you need to then focus on the details...

Make sure that the diagram identifies the data, a process and the output of that process

There is no need to define the process in detail, just a descriptive name for a process...

It's a good way to define a road map to attack the details...

The devil is, as they say, in the details

That will come soon enough

But until you get a picture, it's a forect through the trees kinda thing

oh, and a big MOO|||Brett does diagrams...