<?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"
	>
<channel>
	<title>Comments on: NULLS AREN’T GOOD!</title>
	<atom:link href="http://www.selfadhesivelabels.com/blog/2007/03/13/nulls-aren%e2%80%99t-good/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.selfadhesivelabels.com/blog/2007/03/13/nulls-aren%e2%80%99t-good/</link>
	<description>Describing our migration to open source software and UK business issues in label printing.</description>
	<pubDate>Wed, 20 Aug 2008 21:48:53 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: rich</title>
		<link>http://www.selfadhesivelabels.com/blog/2007/03/13/nulls-aren%e2%80%99t-good/#comment-31</link>
		<dc:creator>rich</dc:creator>
		<pubDate>Mon, 19 Mar 2007 10:15:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.selfadhesivelabels.com/blog/2007/03/13/nulls-aren%e2%80%99t-good/#comment-31</guid>
		<description>Ahh I see what you mean Greg, i.e INSERT INTO table VALUES (NULL, .....) then?

Its a good idea for some of our tables actually, some of the smaller ones anyway, but some bigger tables we use have loads of NULL values, which im understanding is pretty bad in a database anyway. The only way I can see to overcome them is do a mass table update to change their values in the table to non-null, like above (which is time consuming and doesnt seem ideal to be honest), or change the field to allow nulls and do what you said. The only issue I can see with this is the way MSSQL exports the data, because it just gives you '','' for nulls instead of something useful such as NULL.. but im starting to see we could benifit from the info, so muchly apreciated!</description>
		<content:encoded><![CDATA[<p>Ahh I see what you mean Greg, i.e INSERT INTO table VALUES (NULL, &#8230;..) then?</p>
<p>Its a good idea for some of our tables actually, some of the smaller ones anyway, but some bigger tables we use have loads of NULL values, which im understanding is pretty bad in a database anyway. The only way I can see to overcome them is do a mass table update to change their values in the table to non-null, like above (which is time consuming and doesnt seem ideal to be honest), or change the field to allow nulls and do what you said. The only issue I can see with this is the way MSSQL exports the data, because it just gives you &#8221;,&#8221; for nulls instead of something useful such as NULL.. but im starting to see we could benifit from the info, so muchly apreciated!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg</title>
		<link>http://www.selfadhesivelabels.com/blog/2007/03/13/nulls-aren%e2%80%99t-good/#comment-21</link>
		<dc:creator>Greg</dc:creator>
		<pubDate>Tue, 13 Mar 2007 16:39:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.selfadhesivelabels.com/blog/2007/03/13/nulls-aren%e2%80%99t-good/#comment-21</guid>
		<description>Hiya, finding your posts pretty interesting, just thought I'd let you know that Postgres does allow NULL ints, but you have to explicitly state them as null, leaving it as "INSERT INTO (...) VALUES (...,,...)" (two ,s next to each other) won't work...</description>
		<content:encoded><![CDATA[<p>Hiya, finding your posts pretty interesting, just thought I&#8217;d let you know that Postgres does allow NULL ints, but you have to explicitly state them as null, leaving it as &#8220;INSERT INTO (&#8230;) VALUES (&#8230;,,&#8230;)&#8221; (two ,s next to each other) won&#8217;t work&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
