<?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: MongoNYC</title>
	<atom:link href="http://blog.arc90.com/2010/05/27/mongonyc/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.arc90.com/2010/05/27/mongonyc/</link>
	<description>Web Application Design &#38; Development</description>
	<lastBuildDate>Fri, 03 Feb 2012 03:55:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Karl Guertin</title>
		<link>http://blog.arc90.com/2010/05/27/mongonyc/#comment-6346</link>
		<dc:creator>Karl Guertin</dc:creator>
		<pubDate>Tue, 01 Jun 2010 16:07:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.arc90.com/?p=772#comment-6346</guid>
		<description>Depends what you mean by concrete examples. More or less every company presenting at the conference started with a relational database and shifted to Mongo, usually because of performance so when they do release the videos for the conf, you could get specifics on why they chose to do so.

I personally would prefer to use a document-oriented database for most applications on the web, which tend to be built from entities that have a core chunk of data (e.g. blog post, user profile) having a number of related properties (title, tags, url) and a minimal need for ad-hoc querying (retrieve comments). The big win is the ability to persist lists/subobjects without having to create tables, perform joins, perform additional queries, etc. This describes a large class of web applications: mail, news feeds, blogs, forums, bug tracking, CMS, etc.

There are certainly domains where I don&#039;t think the model is as natural: sales, CRM, banking, business reporting. The reporting is actually the biggest deal on this list since virtually every application for business wants some sort of analytics to see how well X is working. The closer your app resembles a relational domain like these, the less sense it makes to use a document DB (though it might fit an object db very well). It&#039;s certainly doable, just like you can map list attributes to a relational model, but it&#039;s not natural. Also, if you&#039;re doing the common pattern of integrating a bunch of apps on the database, then it doesn&#039;t make business sense to use something else unless it makes financial sense to migrate everything over, which it almost never does.

The key to deciding between the two comes down to how you choose to model your domain, and that&#039;s where Kyle&#039;s talk was particularly helpful. There&#039;s nothing keeping your app(s) from using both a SQL database and a non-relational one at the same time and, in fact, most of the people presenting were doing just that.

I suspect that this isn&#039;t what as concrete as you&#039;d like, but it really does depend--both on the data and on your environment. This applies even after you&#039;ve chosen to go document oriented. For server web apps, I really like Mongo. I think they made all the design tradeoffs in favor of running normal internet apps. If, on the other hand, I was going to make some sort of contact database for a small business, I&#039;d probably go Couch so people could run it on their laptops and sync back and forth. 

Sorry for the late response, this got eaten by the spam filter when I posted it on Friday. No clue why.</description>
		<content:encoded><![CDATA[<p>Depends what you mean by concrete examples. More or less every company presenting at the conference started with a relational database and shifted to Mongo, usually because of performance so when they do release the videos for the conf, you could get specifics on why they chose to do so.</p>
<p>I personally would prefer to use a document-oriented database for most applications on the web, which tend to be built from entities that have a core chunk of data (e.g. blog post, user profile) having a number of related properties (title, tags, url) and a minimal need for ad-hoc querying (retrieve comments). The big win is the ability to persist lists/subobjects without having to create tables, perform joins, perform additional queries, etc. This describes a large class of web applications: mail, news feeds, blogs, forums, bug tracking, CMS, etc.</p>
<p>There are certainly domains where I don&#8217;t think the model is as natural: sales, CRM, banking, business reporting. The reporting is actually the biggest deal on this list since virtually every application for business wants some sort of analytics to see how well X is working. The closer your app resembles a relational domain like these, the less sense it makes to use a document DB (though it might fit an object db very well). It&#8217;s certainly doable, just like you can map list attributes to a relational model, but it&#8217;s not natural. Also, if you&#8217;re doing the common pattern of integrating a bunch of apps on the database, then it doesn&#8217;t make business sense to use something else unless it makes financial sense to migrate everything over, which it almost never does.</p>
<p>The key to deciding between the two comes down to how you choose to model your domain, and that&#8217;s where Kyle&#8217;s talk was particularly helpful. There&#8217;s nothing keeping your app(s) from using both a SQL database and a non-relational one at the same time and, in fact, most of the people presenting were doing just that.</p>
<p>I suspect that this isn&#8217;t what as concrete as you&#8217;d like, but it really does depend&#8211;both on the data and on your environment. This applies even after you&#8217;ve chosen to go document oriented. For server web apps, I really like Mongo. I think they made all the design tradeoffs in favor of running normal internet apps. If, on the other hand, I was going to make some sort of contact database for a small business, I&#8217;d probably go Couch so people could run it on their laptops and sync back and forth. </p>
<p>Sorry for the late response, this got eaten by the spam filter when I posted it on Friday. No clue why.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Corey</title>
		<link>http://blog.arc90.com/2010/05/27/mongonyc/#comment-6202</link>
		<dc:creator>Corey</dc:creator>
		<pubDate>Fri, 28 May 2010 20:03:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.arc90.com/?p=772#comment-6202</guid>
		<description>Hey, Karl.

I&#039;ve been looking at Mongo among others lately, after hearing one of their founders on the techzing podcast. I&#039;m still struggling with concrete examples of when you would use a NoSQL db. Was this covered? Any links to share?

Thanks.</description>
		<content:encoded><![CDATA[<p>Hey, Karl.</p>
<p>I&#8217;ve been looking at Mongo among others lately, after hearing one of their founders on the techzing podcast. I&#8217;m still struggling with concrete examples of when you would use a NoSQL db. Was this covered? Any links to share?</p>
<p>Thanks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

