<?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/"
		>
<channel>
	<title>Comments on: Flexible Schemas and PostgreSQL</title>
	<atom:link href="http://thoughts.j-davis.com/2010/05/06/flexible-schemas-and-postgresql/feed/" rel="self" type="application/rss+xml" />
	<link>http://thoughts.j-davis.com/2010/05/06/flexible-schemas-and-postgresql/</link>
	<description>Ideas on Databases, Logic, and Language by Jeff Davis</description>
	<lastBuildDate>Tue, 18 Oct 2011 07:43:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Jeff Davis</title>
		<link>http://thoughts.j-davis.com/2010/05/06/flexible-schemas-and-postgresql/comment-page-1/#comment-206</link>
		<dc:creator>Jeff Davis</dc:creator>
		<pubDate>Thu, 06 May 2010 19:15:12 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=267#comment-206</guid>
		<description>This isn&#039;t the same as EAV. EAV is a complete rejection of the idea of a schema at all, while pretending to use an RDBMS. 

A schema is a constraint, and there are degrees of constraints. The more constrained the data is, the more meaningful reports you can create, which is critical. But in order to constrain your data, you must understand it, and we don&#039;t always understand our data during the exploratory phase of application development.

The point is that we shouldn&#039;t pretend to understand our data by declaring a sophisticated schema when we don&#039;t really understand our data that well. That will only leave a false sense of certainty and add confusion (and therefore bugs).

During early development, even our verbal conversations tend to use vague nouns such as &quot;stuff&quot; and &quot;properties&quot;. The most important rule of database design is that your database should represent reality (including vagueness), not what we wish reality was.</description>
		<content:encoded><![CDATA[<p>This isn&#8217;t the same as EAV. EAV is a complete rejection of the idea of a schema at all, while pretending to use an RDBMS. </p>
<p>A schema is a constraint, and there are degrees of constraints. The more constrained the data is, the more meaningful reports you can create, which is critical. But in order to constrain your data, you must understand it, and we don&#8217;t always understand our data during the exploratory phase of application development.</p>
<p>The point is that we shouldn&#8217;t pretend to understand our data by declaring a sophisticated schema when we don&#8217;t really understand our data that well. That will only leave a false sense of certainty and add confusion (and therefore bugs).</p>
<p>During early development, even our verbal conversations tend to use vague nouns such as &#8220;stuff&#8221; and &#8220;properties&#8221;. The most important rule of database design is that your database should represent reality (including vagueness), not what we wish reality was.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Broersma Jr.</title>
		<link>http://thoughts.j-davis.com/2010/05/06/flexible-schemas-and-postgresql/comment-page-1/#comment-205</link>
		<dc:creator>Richard Broersma Jr.</dc:creator>
		<pubDate>Thu, 06 May 2010 18:29:42 +0000</pubDate>
		<guid isPermaLink="false">http://thoughts.j-davis.com/?p=267#comment-205</guid>
		<description>It seems that HStore serves the same purpose as an EAV table.  Are there any advantages of using HStore over the EAV model?</description>
		<content:encoded><![CDATA[<p>It seems that HStore serves the same purpose as an EAV table.  Are there any advantages of using HStore over the EAV model?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

