In SQL Server, what do you guys use extended properties for? Some articles and blogs are suggesting they be used for self-documentation of the database and its objects but I can't see this being used properly... is this largely ignored by most?

  • 1
    We're using extended properties to document tables and columns, based on a self-written documentation generator which reads the database and produces wiki pages from those extended properties.
    – marc_s
    Feb 8 '13 at 8:46
  • There is no right or wrong answer to this question, it is a matter of opinion and where you work as to what the functionality is used for. As a consultant I see it used all the time for various things from generating stored procedure code to satisfying DoD security standards/policies.
    – user507
    Sep 1 '14 at 1:57

Largely ignored, as you're saying.

Extended properties are a bit awkward to read and write both from T-SQL and GUI. IMHO documentation should be maintained elsewhere (database projects, project documentation etc.).

Here's a good article on extended properties, which also addresses some of your doubts.

  • 1
    I so want to downvote you for that link... articles that require a login are so damn annoying.
    – WernerCD
    Feb 7 '13 at 21:44
  • 1
    @WernerCD: I'd downvote you heavily for being a part of the SQL Server community and not having a free account on SQLServerCentral. It's not as if they're ExpertSexChange...:-D
    – Marian
    Feb 8 '13 at 16:40
  • @Marian I actually think I have an account... it's still annoying to have to log in. As a programmer, it's my duty to be lazy. :)
    – WernerCD
    Feb 8 '13 at 21:20
  • @WernerCD: Oh come on, then try Lastpass, 1password or Roboform or whatever suits you. There are tools for lazy asses. Mine's perfectly suited by Lastpass, but you might find another.
    – Marian
    Feb 8 '13 at 21:27

I'm working with a system where we have numerous databases. Self-documenting is useful because each database can have a different structure.

We manage a database-structure version process and store that information in the extended properties. We also capture descriptions of tables, columns and other database objects.

Working with extended properties would be unmanageable without help from automation though. We developed tools that help us capture and store the information in the extended properties. And, we also have tools to view and report the information.

Developing the tools has been useful in this environment, but I don't see the benefit if your working in a shop where you have very few databases.


I have not yet seen a single project that used extended properties. IMO the reason is this: even if we want to store documentation in the database, which is usually not the case, there are alternatives. Usually extended properties do not do exactly what we want. On the other hand, rolling out our own solution that does exactly what we need is so easy, so why bother?


In our projects we use them for keeping versioning information in extended properties set per database.

Eg: We use Team Foundation projects and we track in a db extended property the last post deployment script number that was executed from the post deployment folder (eg - we have scripts 1 to 23, the ext. property is set to 15, so the post deployment script will execute only scripts from 16 and further). Same for pre-deployment scripts.

I agree that we could keep that info in a table, but it's a way to use extended properties.


Here's an example data dictionary script that makes heavy use of table and column descriptions that shows how useful they can be for self documenting, http://www.csvreader.com/posts/data_dictionary.php .

Not the answer you're looking for? Browse other questions tagged or ask your own question.