<?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: The Era of &#8220;Big Data&#8221; Applications</title>
	<atom:link href="http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/</link>
	<description>Aster Data CEO Blog</description>
	<lastBuildDate>Tue, 03 May 2011 15:13:55 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: The Data Blog: Aster Data Blog &#187; Blog Archive &#187; Partnering with SAS Institute for &#8216;Big Data&#8217; Analysis</title>
		<link>http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/comment-page-1/#comment-387</link>
		<dc:creator>The Data Blog: Aster Data Blog &#187; Blog Archive &#187; Partnering with SAS Institute for &#8216;Big Data&#8217; Analysis</dc:creator>
		<pubDate>Tue, 03 May 2011 15:13:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.asterdata.com/ceo-blog/?p=58#comment-387</guid>
		<description>[...] which Aster Dataâ€™s 4.0 release uniquely supports. Last week we announced the capability to fully push down analytics application logic inside our MPP database so applications can now inside the database allowing analytics to be performed on massive data [...]</description>
		<content:encoded><![CDATA[<p>[...] which Aster Dataâ€™s 4.0 release uniquely supports. Last week we announced the capability to fully push down analytics application logic inside our MPP database so applications can now inside the database allowing analytics to be performed on massive data [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mayank</title>
		<link>http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/comment-page-1/#comment-115</link>
		<dc:creator>Mayank</dc:creator>
		<pubDate>Thu, 19 Nov 2009 18:17:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.asterdata.com/ceo-blog/?p=58#comment-115</guid>
		<description>Surekha,

I agree with you that &quot;business logic&quot; needs to be separate from &quot;business data&quot;. 

As you point out, the major problem with Stored Procedures is that it put &quot;business logic&quot; deep inside the relational database stack. In fact, relational databases never supported Stored Procedures as elegantly as they supported declarative SQL queries. For relational databases, Stored Procedures are just functions on data - not full applications - that are too dependent on properties of data. Application Servers supported business logic a lot more elegantly than Stored Procedures did. 

But having the logic too far outside the data infrastructure means we&#039;ll keep running out of the memory in the mid-tier for &#039;big data applications&#039;. 

The correct architecture enables applications to be &quot;close&quot; to the data without being &quot;subservient&quot; to it. In other words, applications should have their own life and freedom (exactly as when they would be run in a separate application server) and yet not be too far from the data to make read/write accesses to it difficult.</description>
		<content:encoded><![CDATA[<p>Surekha,</p>
<p>I agree with you that &#8220;business logic&#8221; needs to be separate from &#8220;business data&#8221;. </p>
<p>As you point out, the major problem with Stored Procedures is that it put &#8220;business logic&#8221; deep inside the relational database stack. In fact, relational databases never supported Stored Procedures as elegantly as they supported declarative SQL queries. For relational databases, Stored Procedures are just functions on data &#8211; not full applications &#8211; that are too dependent on properties of data. Application Servers supported business logic a lot more elegantly than Stored Procedures did. </p>
<p>But having the logic too far outside the data infrastructure means we&#8217;ll keep running out of the memory in the mid-tier for &#8216;big data applications&#8217;. </p>
<p>The correct architecture enables applications to be &#8220;close&#8221; to the data without being &#8220;subservient&#8221; to it. In other words, applications should have their own life and freedom (exactly as when they would be run in a separate application server) and yet not be too far from the data to make read/write accesses to it difficult.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: surekha</title>
		<link>http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/comment-page-1/#comment-112</link>
		<dc:creator>surekha</dc:creator>
		<pubDate>Tue, 17 Nov 2009 20:29:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.asterdata.com/ceo-blog/?p=58#comment-112</guid>
		<description>I am some what of a mixed opinion on the &quot;move application to data&quot; concept.  The reason being that in the past Stored Procs did try to manipulate data and house business logic in the database but then the industry realized that separation of concerns was important.  To state it another way separating the business logic and rules from the data logic was key to insure that the less volatile business data was not commingled with the more volatile business logic/ rules.  To that effect pushing application logic back to the data tier seems to violate the architecture tenet of separating the business rules from the data tier or for that matter the presentation tier as well.  On the other hand, I can relate to the problem we are seeing in terms of moving tons of data to the mid-tier or the application tier - as we routinely run out of memory on the mid-tier!!

I would love to hear your comments on how AsterData is able to address this concern and this dilemma.

Thanks.
surekha -</description>
		<content:encoded><![CDATA[<p>I am some what of a mixed opinion on the &#8220;move application to data&#8221; concept.  The reason being that in the past Stored Procs did try to manipulate data and house business logic in the database but then the industry realized that separation of concerns was important.  To state it another way separating the business logic and rules from the data logic was key to insure that the less volatile business data was not commingled with the more volatile business logic/ rules.  To that effect pushing application logic back to the data tier seems to violate the architecture tenet of separating the business rules from the data tier or for that matter the presentation tier as well.  On the other hand, I can relate to the problem we are seeing in terms of moving tons of data to the mid-tier or the application tier &#8211; as we routinely run out of memory on the mid-tier!!</p>
<p>I would love to hear your comments on how AsterData is able to address this concern and this dilemma.</p>
<p>Thanks.<br />
surekha -</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Winning with Data &#187; Blog Archive &#187; Partnering with SAS Institute for &#8216;Big Data&#8217; Analysis</title>
		<link>http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/comment-page-1/#comment-109</link>
		<dc:creator>Winning with Data &#187; Blog Archive &#187; Partnering with SAS Institute for &#8216;Big Data&#8217; Analysis</dc:creator>
		<pubDate>Mon, 16 Nov 2009 09:31:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.asterdata.com/ceo-blog/?p=58#comment-109</guid>
		<description>[...] which Aster Dataâ€™s 4.0 release uniquely supports. Last week we announced the capability to fully push down analytics application logic inside our MPP database so applications can now inside the database allowing analytics to be performed on massive data [...]</description>
		<content:encoded><![CDATA[<p>[...] which Aster Dataâ€™s 4.0 release uniquely supports. Last week we announced the capability to fully push down analytics application logic inside our MPP database so applications can now inside the database allowing analytics to be performed on massive data [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake Kaldenbaugh</title>
		<link>http://www.asterdata.com/ceo-blog/index.php/2009/11/02/the-era-of-big-data-applications/comment-page-1/#comment-108</link>
		<dc:creator>Jake Kaldenbaugh</dc:creator>
		<pubDate>Thu, 12 Nov 2009 00:58:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.asterdata.com/ceo-blog/?p=58#comment-108</guid>
		<description>I like your aha! moment.  I&#039;ve been arguing that one of the major problems with current architectures is that each app is building its own data pool.  Companies will be able to get a competitive advantage by making applications logic and presentation layers over a single pool of all of their data.</description>
		<content:encoded><![CDATA[<p>I like your aha! moment.  I&#8217;ve been arguing that one of the major problems with current architectures is that each app is building its own data pool.  Companies will be able to get a competitive advantage by making applications logic and presentation layers over a single pool of all of their data.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

