Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by David Poole » Oiling the gears for the data dictionary
Add to briefcase
14 posts, Page 1 of 2
12»»

Oiling the gears for the data dictionary Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
David.Poole
Posted Wednesday, February 16, 2011 10:53 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:46 AM
Points: 2,750, Visits: 1,410
Comments posted to this topic are about the item Oiling the gears for the data dictionary

LinkedIn Profile
Post #1065439
Satnam Singh
Posted Thursday, February 17, 2011 12:22 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 5:14 AM
Points: 291, Visits: 1,066
Great article David. Keep up the Good Work going. Many Thanks for sharing with us.

Cheers,
Satnam
Post #1065461
Vedran Kesegic
Posted Thursday, February 17, 2011 1:48 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 6:00 PM
Points: 343, Visits: 1,077
Documenting the database is very important.
You can see descriptions next to the table columns quite easily with XDetails plugin (free): www.sqlxdetails.com

_____________________________________________________
XDetails Addin - for SQL Developers and DBA
blog.sqlxdetails.com - Transaction log myths - debunked!
Post #1065492
James A Skipwith
Posted Thursday, February 17, 2011 2:20 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, February 22, 2013 8:20 AM
Points: 59, Visits: 276
David,

This is exactly how I do it!

Nice article.

James

James
MCM [@TheSQLPimp]
Post #1065506
Kiara
Posted Thursday, February 17, 2011 5:13 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, May 01, 2013 6:14 AM
Points: 592, Visits: 1,423
Very useful article. Thanks very much for writing it.

-Ki
Post #1065570
Dennis Wagner-347763
Posted Thursday, February 17, 2011 6:46 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, January 17, 2013 5:28 AM
Points: 42, Visits: 170
David, very nice! Of course, it all comes down to someone putting in the descriptions for each field or you just get a list of tables and columns.

I'd be interested in knowing how many DBAs/Developers take the time to actually fill in the descriptions. It would also be very interesting to see how many do this for commercial systems where the client requests a data dictionary vs. internal systems that are only used in house.
Post #1065621
ACinKC
Posted Thursday, February 17, 2011 7:05 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, March 21, 2013 3:53 PM
Points: 114, Visits: 916
I'm part of a project developing an application for states to use when managing various programs. As such, we have to provide a data dictionary as part of the deliverables, but some of the descriptions the developers supplied are things like "this is the ID field" or "disscribs the person" [sic]...Not helpful and not accurate, and shows that, sometimes, developers aren't the best at using English! I created an Excel/VBA tool to pull the table names from the database, create a tab for each table and populate the new worksheet with table and field names, and also the extended properties for each. At each milestone in the project, we deliver the Excel file to the documentation department for "wordsmithing", then another button on the Excel file updates (or inserts) the MS_Description property in the master database. Quick, easy, adapts to changes in the tables, and allows the developers to concentrate on writing code, while the documentation folk get to do what they get paid for.

The only hiccup in your detection of blank extended attributes is when the developer uses "Must populate this" as their description for each and every field in the tables they create!
Post #1065637
roger.plowman
Posted Thursday, February 17, 2011 7:13 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: 2 days ago @ 7:11 AM
Points: 317, Visits: 619
Personally I think the data dictionary approach would be better served using a data modeling tool like Toad Data Modeller or Rational Rose. (I use Toad myself).

That way not only do you have the tables laid out graphically, showing relationships, you also have the comments for each table and field, plus any functions, and if you use the built in domain tools you have consistancy across tables for things like zip codes, phone numbers, etc.

Since I wrote a small Access tool to generate the basic stored procedures and it has the ability to let me create more complex SPs myself (along with notes, etc) I find I don't rely so much on SQL Server for documentation.

IMO a dedicated data modeller is the most logical place for documentation anyway, since it basically is both documentation *and* script creation tool.
Post #1065643
dave.clark
Posted Thursday, February 17, 2011 9:30 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, May 14, 2013 2:51 PM
Points: 42, Visits: 351
Dennis Wagner-347763 (2/17/2011)
It would also be very interesting to see how many do this for commercial systems where the client requests a data dictionary vs. internal systems that are only used in house.


At my company, we force application developers to submit database requests with descriptions for the objects. This is enforced through the intranet page where they submit the request. Additionally we review the descriptions to make sure they make sense!

The extended properties are released to all of our customers. We also use these properties for an internal data dictionary as well as an external data dictionary that our customers can view by logging on to our customer support web site. Even though the information is in the customer's database we provide the information on the web site for those customers that aren't familiar with getting the information through T-SQL in the database.
Post #1065780
matthew.greenslade-881391
Posted Thursday, February 17, 2011 9:32 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, May 22, 2013 3:55 AM
Points: 1, Visits: 55
Good article. I am writing some .net code to manage SQL Server Extended Properties across all our servers including managing different 'sets' of extended properties, bulk copying and pasting of properties from database to database, table to table and even field to field.

Its likely to be a few more weeks in production but I can put some details up if I get it running. It doesnt hold properties in a table though, they are dynamically queried.
Post #1065781
« Prev Topic | Next Topic »

Add to briefcase
14 posts, Page 1 of 2
12»»

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.