SQL Server Team-based Development - Red Gate Software

Chapter 2: Documenting your Database
to code, the same is not true of tables in SQL Server. When you script out a table in
SSMS, or via SMO, you'll notice that table build scripts have lost any comments that you
put in them.
This may or may not present a problem. It depends on how you develop databases. There
are two basic ways of developing databases: one, where the script is the primary source,
and the other, where the database is considered to be the source. If you are doing the
former, and you run a fiendishly clever source-control system, then you don't have a
problem, but otherwise, you will have to put your structured header in an "extended
property" of the table.
The first method of developing databases involves maintaining one or more build scripts
which contain all the comment blocks and inline comments. This is used to generate the
database, but the process is never reversed. The second method avoids the meticulous
source-control systems that the script-based method involved. The current version of
the development database effectively becomes the source, and the state of the database is
"pulled off" at regular intervals as a build script, using SMO or a third-party tool, such as
SQL Compare. Each developer alters a database routine by first scripting off the routine
he is working on using SSMS.
If you use the latter method of developing databases, then you have to use extended
properties to store your header information, rather than storing it with the code itself, in
the header.
Extended properties
There are problems in using extended properties as an alternative to headers, because
GUIs generally only allow access to the ones that are used by SSMS, and that boils down
to one extended property called MS_Documentation. This, by itself, isn't enough.
Even if you define extra properties to store different types of information, you still face
problems with lists, such as revision lists, since one cannot have more than one instance
48