Good Thing you have been introduced

it really help in documentation ... related thing........

Hi,

about Tools: I made good experiences with Enterprise Architect from Sparx Systems . It is a software modelling tool. http://www.sparxsystems.com.au/

You can import DDL Schemas by using OLEDB and ODBC connections to many database systems. The tool reads the extended Properties from SQL Server Objects and from others (DB2).

You can edit the DDL with a GUI and export DDL scripts.

Best regards,

Stefan

From my experience it's not just about documenting the objects, but how they're accessed and their purpose; and ensuring that the documentation is up to date.  MS Word, as the author suggests, requires someone to keep it up to date; and we all know how well that turns out.  There are many tools out there, all with their good points, but I personally wouldn't ever consider one which didn't offer me the ability to run as part of a build, or nightly task.

On the subject of tools; my shameless plug is for DBDocumentor from Pikauba Software (http://www.pikauba.com/DBDoc/details.htm).  It works from the SQL sources so it won't be for everyone, but the tradeoff is that you can get information about result sets and data accesses/modifications.  It also has support for SSRS RDL, so that's a good bonus.

Cheers

I've been doing this for quite a while now.  Version before 2005 did not support extended properties for tables well.  I wanted a unified system.  So:

CREATE TABLE [doc_Fields] (
  [TableName] [varchar] (50),
  [FieldName] [varchar] (50),
  [Comment] [varchar] (4000)
) ON [PRIMARY]

I then put my field and table descriptions here.  If the field name is blank, or NULL, then Comment applies to the table.  A little grid based program to make the entry easy and one to generate an RTF file.

Now ported to .Net and using the extended properties it serves us well.  The advantage of the extended properties is that when I generate create scripts the comments come along.  This is also a help to the UI teams.  They can use this to generate tool tips.

This may not have been mentioned in the article because it's too obvious, but I consider a database relational diagram to be one of the most important pieces of documentation for any database.  I usually create one with only the "core" tables but detailed column information and another with all tables including "look-up"s but with less column detail.

I also use the following sql to list tables, columns, and the "Description" text that EM's "Design Table" lets you enter.  I save the results to Excel and add the spreadsheet to my database documentation.

Note: This works on SQL 2000.  I have not tried it on SQL 7.0 or 2005 (yet) but it probably needs adjusting because it uses system tables.

--List tables, columns and column descriptions
select SO.name as 'table', SC.name as field,
ST.name as datatype, SC.length as 'size',
sp.value as 'description'
from syscolumns SC inner join
sysobjects SO on SC.id = SO.id inner join
systypes ST on ST.xusertype = SC.xusertype left join
sysproperties sp on  sp.id = so.id and sp.smallid = SC.colid
where SO.xtype = 'U' and SO.status > 0
order by SO.name, SC.name

CORRECTION.  The prior posted sql may have duplicates.  The following should work better:

--List tables, columns and column descriptions
select SO.name as 'table', SC.name as field,
ST.name as datatype, SC.length as 'size',
sp.value as 'description'
from syscolumns SC inner join
sysobjects SO on SC.id = SO.id inner join
systypes ST on ST.xusertype = SC.xusertype left join
sysproperties sp on  sp.id = so.id and sp.smallid = SC.colid
and sp.name = 'MS_Description'
where SO.xtype = 'U' and SO.status > 0
order by SO.name, SC.name