<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Deprecation within Database Schemas</title>
	<atom:link href="http://mauszeig.wordpress.com/2007/09/08/deprecation-within-database-schemas/feed/" rel="self" type="application/rss+xml" />
	<link>http://mauszeig.wordpress.com/2007/09/08/deprecation-within-database-schemas/</link>
	<description>Eclipse, GIS development and news from the agile data trenches</description>
	<lastBuildDate>Thu, 08 Oct 2009 13:24:05 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Scott W. Ambler</title>
		<link>http://mauszeig.wordpress.com/2007/09/08/deprecation-within-database-schemas/#comment-8683</link>
		<dc:creator>Scott W. Ambler</dc:creator>
		<pubDate>Tue, 11 Sep 2007 05:36:01 +0000</pubDate>
		<guid isPermaLink="false">http://mauszeig.wordpress.com/2007/09/08/deprecation-within-database-schemas/#comment-8683</guid>
		<description>This is something that Pramod Sadalage and I wrote about in Refactoring Databases, http://www.ambysoft.com/books/refactoringDatabases.html

To effectively communicate deprecation within a database you would need to:
1. Automatically support it within the database itself as you imply above.  This would imply that the database should throw a low-level warning when you access something that&#039;s deprecated.  This implies an architectural change to the DB itself, something that the vendors would need to do.
2. Support deprecation within physical data models.  I&#039;ve also proposed UML modeling notation for that at http://www.agiledata.org/essays/umlDataModelingProfile.html, a notation that we use in the book.   This is something that the data modeling tool vendors would need to support.
3. Get people working in this sort of manner.  This requires a cultural change, something which always takes time.

- Scott
Practice Leader Agile Development, IBM Rational</description>
		<content:encoded><![CDATA[<p>This is something that Pramod Sadalage and I wrote about in Refactoring Databases, <a href="http://www.ambysoft.com/books/refactoringDatabases.html" rel="nofollow">http://www.ambysoft.com/books/refactoringDatabases.html</a></p>
<p>To effectively communicate deprecation within a database you would need to:<br />
1. Automatically support it within the database itself as you imply above.  This would imply that the database should throw a low-level warning when you access something that&#8217;s deprecated.  This implies an architectural change to the DB itself, something that the vendors would need to do.<br />
2. Support deprecation within physical data models.  I&#8217;ve also proposed UML modeling notation for that at <a href="http://www.agiledata.org/essays/umlDataModelingProfile.html" rel="nofollow">http://www.agiledata.org/essays/umlDataModelingProfile.html</a>, a notation that we use in the book.   This is something that the data modeling tool vendors would need to support.<br />
3. Get people working in this sort of manner.  This requires a cultural change, something which always takes time.</p>
<p>- Scott<br />
Practice Leader Agile Development, IBM Rational</p>
]]></content:encoded>
	</item>
</channel>
</rss>
