<?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: If you only learn one thing about database transactions, it should be this</title>
	<atom:link href="http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/</link>
	<description>Stay curious!</description>
	<lastBuildDate>Thu, 09 Feb 2012 20:41:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Rue Plumet &#187; Interesting Sites For This Week</title>
		<link>http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/#comment-1698</link>
		<dc:creator>Rue Plumet &#187; Interesting Sites For This Week</dc:creator>
		<pubDate>Mon, 04 Sep 2006 02:37:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=212#comment-1698</guid>
		<description>&lt;p&gt;[...] If you only learn one thing about database transactions, it should be this Tagged as: database design [...]&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>[...] If you only learn one thing about database transactions, it should be this Tagged as: database design [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate K</title>
		<link>http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/#comment-1652</link>
		<dc:creator>Nate K</dc:creator>
		<pubDate>Mon, 28 Aug 2006 13:38:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=212#comment-1652</guid>
		<description>&lt;p&gt;This is a great list. I think its overlooked by many that work with databases. Your comparison of &#039;running out into the rain&#039; hit the nail on the head for me. Get in, get your work done, and get out. It shouldn&#039;t be a trivial process.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>This is a great list. I think its overlooked by many that work with databases. Your comparison of &#8216;running out into the rain&#8217; hit the nail on the head for me. Get in, get your work done, and get out. It shouldn&#8217;t be a trivial process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/#comment-1651</link>
		<dc:creator>Xaprb</dc:creator>
		<pubDate>Mon, 28 Aug 2006 12:44:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=212#comment-1651</guid>
		<description>&lt;p&gt;James, that&#039;s a great addition.  Peter, I agree.  I actually advised a client to go this way recently -- store incremental updates into a staging table, then apply updates from the staging table every ten minutes.  It helps him get some more benefit from the query cache, too.  We actually experimented with a good batch size at my employer when I was writing our archiving and purging jobs (see past articles), and found 1,000 rows worked very well -- it is small enough that it doesn&#039;t block much, but it isn&#039;t constantly trying to flush things to the disk either.  It was many hundreds of times faster than a row at a time.  So -- when I say &quot;as small as possible&quot; I don&#039;t mean a row at a time, I mean don&#039;t do unnecessary work.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>James, that&#8217;s a great addition.  Peter, I agree.  I actually advised a client to go this way recently &#8212; store incremental updates into a staging table, then apply updates from the staging table every ten minutes.  It helps him get some more benefit from the query cache, too.  We actually experimented with a good batch size at my employer when I was writing our archiving and purging jobs (see past articles), and found 1,000 rows worked very well &#8212; it is small enough that it doesn&#8217;t block much, but it isn&#8217;t constantly trying to flush things to the disk either.  It was many hundreds of times faster than a row at a time.  So &#8212; when I say &#8220;as small as possible&#8221; I don&#8217;t mean a row at a time, I mean don&#8217;t do unnecessary work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Zaitsev</title>
		<link>http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/#comment-1650</link>
		<dc:creator>Peter Zaitsev</dc:creator>
		<pubDate>Mon, 28 Aug 2006 12:01:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=212#comment-1650</guid>
		<description>&lt;p&gt;Keep you transactions as small as possible is something I would be careful with.  I&#039;ve seen people doing 1.000.000 transactions to insert 1.000.000 rows. It is not smart ether as commit overhead is going to be significant. &lt;/p&gt;

&lt;p&gt;If you have batch operations medium size transactions are best, so commit overhead is not going to hurt you while you&#039;re not possibly blocking things for a lot of times due to locks :)&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>Keep you transactions as small as possible is something I would be careful with.  I&#8217;ve seen people doing 1.000.000 transactions to insert 1.000.000 rows. It is not smart ether as commit overhead is going to be significant. </p>
<p>If you have batch operations medium size transactions are best, so commit overhead is not going to hurt you while you&#8217;re not possibly blocking things for a lot of times due to locks :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Day</title>
		<link>http://www.xaprb.com/blog/2006/08/27/if-you-only-learn-one-thing-about-database-transactions-it-should-be-this/#comment-1649</link>
		<dc:creator>James Day</dc:creator>
		<pubDate>Mon, 28 Aug 2006 10:36:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.xaprb.com/blog/?p=212#comment-1649</guid>
		<description>&lt;p&gt;One other thing you can try is ensuring that the data is in the database server cache with a select outside the transaction. Adds to the general server load so it&#039;s mostly of interest in areas where contention is greatest, not as a general design rule.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>One other thing you can try is ensuring that the data is in the database server cache with a select outside the transaction. Adds to the general server load so it&#8217;s mostly of interest in areas where contention is greatest, not as a general design rule.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

