<?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: Should you go Beyond Relational Databases?</title>
	<atom:link href="http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/feed/" rel="self" type="application/rss+xml" />
	<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/</link>
	<description></description>
	<lastBuildDate>Sat, 20 Mar 2010 00:35:05 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: InfoGrid Blog - Carsonified: Why Graph Databases</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-16112</link>
		<dc:creator>InfoGrid Blog - Carsonified: Why Graph Databases</dc:creator>
		<pubDate>Wed, 28 Oct 2009 17:20:38 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-16112</guid>
		<description>[...] Kleppman summarizes the case for Graph Databases at carsonified.com. This is exactly why InfoGrid is built around a [...]</description>
		<content:encoded><![CDATA[<p>[...] Kleppman summarizes the case for Graph Databases at carsonified.com. This is exactly why InfoGrid is built around a [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Neo Technology Secures Seed Funding To Lead NoSQL Movement</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-16099</link>
		<dc:creator>Neo Technology Secures Seed Funding To Lead NoSQL Movement</dc:creator>
		<pubDate>Wed, 28 Oct 2009 10:41:47 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-16099</guid>
		<description>[...] both the future of databases and Neo Technology, but until then I highly recommend this excellent article by Martin Kleppmann. It gives you a great overview of different database models and an excellent [...]</description>
		<content:encoded><![CDATA[<p>[...] both the future of databases and Neo Technology, but until then I highly recommend this excellent article by Martin Kleppmann. It gives you a great overview of different database models and an excellent [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eamonn O&#8217;Brien-Strain :: links for 2009-09-20</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-15244</link>
		<dc:creator>Eamonn O&#8217;Brien-Strain :: links for 2009-09-20</dc:creator>
		<pubDate>Sun, 20 Sep 2009 23:04:31 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-15244</guid>
		<description>[...] Carsonified » Should you go Beyond Relational Databases? Nicely organized overview of non-SQL databases. (tags: programming database scaling) [...]</description>
		<content:encoded><![CDATA[<p>[...] Carsonified » Should you go Beyond Relational Databases? Nicely organized overview of non-SQL databases. (tags: programming database scaling) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Python Paradox is now the Scala Paradox &#8211; Martin Kleppmann at Yes/No/Cancel</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-15214</link>
		<dc:creator>The Python Paradox is now the Scala Paradox &#8211; Martin Kleppmann at Yes/No/Cancel</dc:creator>
		<pubDate>Fri, 18 Sep 2009 22:32:36 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-15214</guid>
		<description>[...] an article about non-relational databases which Ryan Carson asked me to write a few months ago, I suggested that fashion can and should play [...]</description>
		<content:encoded><![CDATA[<p>[...] an article about non-relational databases which Ryan Carson asked me to write a few months ago, I suggested that fashion can and should play [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Más allá de las bases de datos relacionales en El blog de Javier Aranda</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-14420</link>
		<dc:creator>Más allá de las bases de datos relacionales en El blog de Javier Aranda</dc:creator>
		<pubDate>Sat, 29 Aug 2009 23:08:43 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-14420</guid>
		<description>[...] Traducción libre del texto original Should you go Beyond Relational Databases? by Martin Kleppmann [...]</description>
		<content:encoded><![CDATA[<p>[...] Traducción libre del texto original Should you go Beyond Relational Databases? by Martin Kleppmann [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Silver</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-12685</link>
		<dc:creator>Jerry Silver</dc:creator>
		<pubDate>Mon, 03 Aug 2009 23:41:04 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-12685</guid>
		<description>You can find more information on EMC&#039;s native XML database, xDB, at http://developer.emc.com/xmltech.  Free download too.</description>
		<content:encoded><![CDATA[<p>You can find more information on EMC&#8217;s native XML database, xDB, at <a href="http://developer.emc.com/xmltech" rel="nofollow">http://developer.emc.com/xmltech</a>.  Free download too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Popescu</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-12520</link>
		<dc:creator>Alex Popescu</dc:creator>
		<pubDate>Sat, 01 Aug 2009 21:45:07 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-12520</guid>
		<description>1. Very nice post! A while back I&#039;ve started a comparison of &quot;alternative&quot; data storage solution. It&#039;s far from being complete, I think it might offer some quite details to newcomers (http://themindstorms.blogspot.com/2009/05/quick-reference-to-alternative-data.html).

2. I&#039;ve been using BDB as a storage implementation of Jackrabbit for 4 years. It was couple of days ago (in fact it happened exactly on Jul. 30th, the date of the last comment mentioning failures of BDB) that this database got corrupted.

3. There are a couple of things about all these solution that concern me and I&#039;m referring here to the fact that most of them have chosen to implement custom protocols and connection APIs. While I may find some reasons for this (f.e. most of them have been initially developed to solve an internal problem and open sourced afterwards), it is quite strange to see that they lock you in. Basically, before starting to use any of these solution you&#039;ll have to spend a lot more time to figure out if the solution you are picking will fit all your needs, as later migration will be extremely difficult.

I hope there will be a time when people involved will sit down and figure out some common protocols and APIs. And I hope this will happen sooner than later, as the more we postpone this step the more difficult will be to ask those already using to change their implementations.</description>
		<content:encoded><![CDATA[<p>1. Very nice post! A while back I&#8217;ve started a comparison of &#8220;alternative&#8221; data storage solution. It&#8217;s far from being complete, I think it might offer some quite details to newcomers (<a href="http://themindstorms.blogspot.com/2009/05/quick-reference-to-alternative-data.html" rel="nofollow">http://themindstorms.blogspot.com/2009/05/quick-reference-to-alternative-data.html</a>).</p>
<p>2. I&#8217;ve been using BDB as a storage implementation of Jackrabbit for 4 years. It was couple of days ago (in fact it happened exactly on Jul. 30th, the date of the last comment mentioning failures of BDB) that this database got corrupted.</p>
<p>3. There are a couple of things about all these solution that concern me and I&#8217;m referring here to the fact that most of them have chosen to implement custom protocols and connection APIs. While I may find some reasons for this (f.e. most of them have been initially developed to solve an internal problem and open sourced afterwards), it is quite strange to see that they lock you in. Basically, before starting to use any of these solution you&#8217;ll have to spend a lot more time to figure out if the solution you are picking will fit all your needs, as later migration will be extremely difficult.</p>
<p>I hope there will be a time when people involved will sit down and figure out some common protocols and APIs. And I hope this will happen sooner than later, as the more we postpone this step the more difficult will be to ask those already using to change their implementations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim McCoy</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-12322</link>
		<dc:creator>Jim McCoy</dc:creator>
		<pubDate>Thu, 30 Jul 2009 05:10:24 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-12322</guid>
		<description>Glenn: While Berkeley DB is good tech, I think that a lot of us got burned by it in the past (three catastrophic loss of entire db situations and two others that required several days to recover from in my own experience of using BDB for more than a decade) and if given the choice today I would always pick Tokyo Cabinet over BDB.  The fact that it is now in Oracle&#039;s hands is not really a point in its favor either.</description>
		<content:encoded><![CDATA[<p>Glenn: While Berkeley DB is good tech, I think that a lot of us got burned by it in the past (three catastrophic loss of entire db situations and two others that required several days to recover from in my own experience of using BDB for more than a decade) and if given the choice today I would always pick Tokyo Cabinet over BDB.  The fact that it is now in Oracle&#8217;s hands is not really a point in its favor either.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Notes from OSCON 2009 in San Jose &#124; ecmarchitect.com</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-12140</link>
		<dc:creator>Notes from OSCON 2009 in San Jose &#124; ecmarchitect.com</dc:creator>
		<pubDate>Mon, 27 Jul 2009 22:04:18 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-12140</guid>
		<description>[...] was the third &#8220;noSQL&#8221;-themed talk I saw. He made a good point that when we design apps, we should be saying, &#8220;I [...]</description>
		<content:encoded><![CDATA[<p>[...] was the third &#8220;noSQL&#8221;-themed talk I saw. He made a good point that when we design apps, we should be saying, &#8220;I [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kai&#8217;s daily tech #44 &#8230; &#124; Kai Richard König</title>
		<link>http://carsonified.com/blog/dev/should-you-go-beyond-relational-databases/#comment-11619</link>
		<dc:creator>Kai&#8217;s daily tech #44 &#8230; &#124; Kai Richard König</dc:creator>
		<pubDate>Sat, 18 Jul 2009 20:08:52 +0000</pubDate>
		<guid isPermaLink="false">http://thinkvitamin.com/?p=1595#comment-11619</guid>
		<description>[...] Carsonified » Should you go Beyond Relational Databases? [...]</description>
		<content:encoded><![CDATA[<p>[...] Carsonified » Should you go Beyond Relational Databases? [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
