<story><title>Rapid schema development with PostgreSQL</title><url>https://speakerdeck.com/andrewgodwin/rapid-schema-development-with-postgresql</url></story><parent_chain><item><author>moron4hire</author><text>I&amp;#x27;m failing to see the utility of hstore or json over adding nullable columns here, especially if the latest version makes adding a nullable column essentially instantaneous. It doesn&amp;#x27;t seem to simplifying the handling of missing&amp;#x2F;unavailable data, but does manage to complicate the SQL syntax.&lt;p&gt;I have clients that use a variety of databases for a variety of reasons, not the least of which is &amp;quot;just because that is where our data is.&amp;quot; All the value of most projects is in the data, and the value of data grows with age, because you cannot recreate the past. If you lose something or you fail to record something, then you can&amp;#x27;t ever get it back in a way that will stand up to audit scrutiny. This has the awful effect of making technology-specific details of databases get pushed into the business-decision realm, rather than the technology-decision realm.&lt;p&gt;So complicating the SQL syntax is a significant issue for me. Sticking to as much standard, ANSI SQL as possible makes my programs more portable across RDBMSes. With some of the tools I&amp;#x27;ve written, I can make a full transition from MySQL to MS SQL Server and back again and the application doesn&amp;#x27;t care. Having that sort of power makes upgrading your database a technology decision, not a business one.&lt;p&gt;Yes, the features that Postgres have are nice, but to me they represent a very great chance of vendor lockin. I don&amp;#x27;t believe that the Postgres team will ever pull anything to make me hate them, but then I thought the same about Sun at one point, too.</text></item></parent_chain><comment><author>DrJokepu</author><text>HStore and especially JSON are useful because they allow you to store complex data structures fairly easily. Do you have something that contains a number of somethings that contain a number of somethings that contain a number of somethings? Normally you would need like, 4 tables to store this and carefully planned queries to work with them efficiently. However, if the object graph has no external references (besides the top-level object) you can just safely shove the whole thing into a JSON without losing referential integrity.&lt;p&gt;Your reasons are very valid however so obviously you have to  think about the consequences before using non-standard features. However, not using advanced or novel features (which non-standard features tend to be) can also lead to stagnation and loss of competitiveness so you have to also be careful with being careful, if that makes sense.</text></comment>
<story><title>Rapid schema development with PostgreSQL</title><url>https://speakerdeck.com/andrewgodwin/rapid-schema-development-with-postgresql</url></story><parent_chain><item><author>moron4hire</author><text>I&amp;#x27;m failing to see the utility of hstore or json over adding nullable columns here, especially if the latest version makes adding a nullable column essentially instantaneous. It doesn&amp;#x27;t seem to simplifying the handling of missing&amp;#x2F;unavailable data, but does manage to complicate the SQL syntax.&lt;p&gt;I have clients that use a variety of databases for a variety of reasons, not the least of which is &amp;quot;just because that is where our data is.&amp;quot; All the value of most projects is in the data, and the value of data grows with age, because you cannot recreate the past. If you lose something or you fail to record something, then you can&amp;#x27;t ever get it back in a way that will stand up to audit scrutiny. This has the awful effect of making technology-specific details of databases get pushed into the business-decision realm, rather than the technology-decision realm.&lt;p&gt;So complicating the SQL syntax is a significant issue for me. Sticking to as much standard, ANSI SQL as possible makes my programs more portable across RDBMSes. With some of the tools I&amp;#x27;ve written, I can make a full transition from MySQL to MS SQL Server and back again and the application doesn&amp;#x27;t care. Having that sort of power makes upgrading your database a technology decision, not a business one.&lt;p&gt;Yes, the features that Postgres have are nice, but to me they represent a very great chance of vendor lockin. I don&amp;#x27;t believe that the Postgres team will ever pull anything to make me hate them, but then I thought the same about Sun at one point, too.</text></item></parent_chain><comment><author>tieTYT</author><text>&lt;a href=&quot;http://www.postgresql.org/docs/9.2/static/datatype-json.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.postgresql.org&amp;#x2F;docs&amp;#x2F;9.2&amp;#x2F;static&amp;#x2F;datatype-json.html&lt;/a&gt;&lt;p&gt;&amp;gt; Such data can also be stored as text, but the json data type has the advantage of checking that each stored value is a valid JSON value. There are also related support functions available</text></comment>