<?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: What is the future of Ajax applications talking to the data tier?</title>
	<atom:link href="http://ajaxian.com/archives/what-is-the-future-of-ajax-applications-talking-to-the-data-tier/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/what-is-the-future-of-ajax-applications-talking-to-the-data-tier</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 18 Mar 2010 15:55:46 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: nextone</title>
		<link>http://ajaxian.com/archives/what-is-the-future-of-ajax-applications-talking-to-the-data-tier/comment-page-1#comment-263012</link>
		<dc:creator>nextone</dc:creator>
		<pubDate>Tue, 22 Apr 2008 08:32:32 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=3572#comment-263012</guid>
		<description>Hi,

Have a look at &lt;a href=&quot;http://www-sor.inria.fr/~dedieu/these.html&quot; rel=&quot;nofollow&quot;&gt;Olivier Dedieu thesis &lt;/a&gt; made 8 years ago.

It is the starting point of a very powerfull Java CMS named &lt;a href=&#039;http://support.jalios.com/jcms/jx_20089/installation-et-prise-en-main-rapide-de-jcms&#039; rel=&quot;nofollow&quot;&gt;Jalios JCMS&lt;/a&gt;. It is a Product and a Platform (available since 2002) use to build CMS/Portal/GED Web Application.

The idea is to load an object graph in memory available to developers throught a powerfull search engine... There is no SQL, you just follow the graph: Channel.getPublication(&#039;c_1234&#039;).getAuthor().getGroups()[1].getName()

Jalios is a growing french company not yet known in US. More on &lt;a href=&#039;http://en.wikipedia.org/wiki/Jalios_JCMS&#039; rel=&quot;nofollow&quot;&gt;wikipedia&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>Have a look at <a href="http://www-sor.inria.fr/~dedieu/these.html" rel="nofollow">Olivier Dedieu thesis </a> made 8 years ago.</p>
<p>It is the starting point of a very powerfull Java CMS named <a href='http://support.jalios.com/jcms/jx_20089/installation-et-prise-en-main-rapide-de-jcms' rel="nofollow">Jalios JCMS</a>. It is a Product and a Platform (available since 2002) use to build CMS/Portal/GED Web Application.</p>
<p>The idea is to load an object graph in memory available to developers throught a powerfull search engine&#8230; There is no SQL, you just follow the graph: Channel.getPublication(&#8217;c_1234&#8242;).getAuthor().getGroups()[1].getName()</p>
<p>Jalios is a growing french company not yet known in US. More on <a href='http://en.wikipedia.org/wiki/Jalios_JCMS' rel="nofollow">wikipedia</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chalia</title>
		<link>http://ajaxian.com/archives/what-is-the-future-of-ajax-applications-talking-to-the-data-tier/comment-page-1#comment-263011</link>
		<dc:creator>chalia</dc:creator>
		<pubDate>Tue, 22 Apr 2008 04:44:57 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=3572#comment-263011</guid>
		<description>I agree with PeterMichaux. I have used several abstract layer for databases. Sometimes, it gona to save lots of time while using SQL instead of those abstract layers such as Active Record. 

For large or medium scale web applications, it will be good to have abstract layers, such as Active Record. But just sometimes, the SQL query will be much easier and quicker. 

And as we are using PHP a lot, it seems that MySQL would be first option all the time.  That is only from developer point of view. 

If someone from database management background gives us some ideas, that will be great</description>
		<content:encoded><![CDATA[<p>I agree with PeterMichaux. I have used several abstract layer for databases. Sometimes, it gona to save lots of time while using SQL instead of those abstract layers such as Active Record. </p>
<p>For large or medium scale web applications, it will be good to have abstract layers, such as Active Record. But just sometimes, the SQL query will be much easier and quicker. </p>
<p>And as we are using PHP a lot, it seems that MySQL would be first option all the time.  That is only from developer point of view. </p>
<p>If someone from database management background gives us some ideas, that will be great</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PeterMichaux</title>
		<link>http://ajaxian.com/archives/what-is-the-future-of-ajax-applications-talking-to-the-data-tier/comment-page-1#comment-263009</link>
		<dc:creator>PeterMichaux</dc:creator>
		<pubDate>Tue, 22 Apr 2008 01:15:06 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=3572#comment-263009</guid>
		<description>I&#039;ve been thinking about this a lot (more) lately as I&#039;ve been fighting with Active Record (in Rails) over the last week to make it mesh with my (good) relational database schema. The following thoughts are larval.

I don&#039;t think the problem is the relational database. I don&#039;t really see the difference between a database and the file system in one way: both are ways to persist data on a disk and both have an API of sorts to do that. An ACID compliant database offers all sorts of goodies that are worthwhile for piece of mind. Our application can use the API for the persistent store to serialize any data. It&#039;s the applications job to figure out how to use that API and hopefully it will be some nice clean code that does that.

I think the problem is using a high-level ORM to map a schema that it wasn&#039;t designed to map. The higher the level the abstraction the more difficult it is to work with if the low-level details it is abstracting change. Active Record works well with single tables and well with some types of table relationships. For other types of relationships that it doesn&#039;t support (e.g. class table inheritance) it takes a great deal of massaging to make it work. I&#039;m sure it took a great deal of massaging to get it to work with the relationships it supports out of the box. And all this could be done with a few lines of SQL...literally. It would be fine if Active Record works well with most schemas or all schemas a particular developer has but that just isn&#039;t the case. It works well most of the time but seems to fail at least somewhere in a project.

SQL is a very high-level but still flexible API for working with stored data. Active Record is a high-level, less flexible API for working with stored data. Perhaps the ORM experiment failed and the RDMBS experiment won? I&#039;m thinking about going back to straight SQL.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been thinking about this a lot (more) lately as I&#8217;ve been fighting with Active Record (in Rails) over the last week to make it mesh with my (good) relational database schema. The following thoughts are larval.</p>
<p>I don&#8217;t think the problem is the relational database. I don&#8217;t really see the difference between a database and the file system in one way: both are ways to persist data on a disk and both have an API of sorts to do that. An ACID compliant database offers all sorts of goodies that are worthwhile for piece of mind. Our application can use the API for the persistent store to serialize any data. It&#8217;s the applications job to figure out how to use that API and hopefully it will be some nice clean code that does that.</p>
<p>I think the problem is using a high-level ORM to map a schema that it wasn&#8217;t designed to map. The higher the level the abstraction the more difficult it is to work with if the low-level details it is abstracting change. Active Record works well with single tables and well with some types of table relationships. For other types of relationships that it doesn&#8217;t support (e.g. class table inheritance) it takes a great deal of massaging to make it work. I&#8217;m sure it took a great deal of massaging to get it to work with the relationships it supports out of the box. And all this could be done with a few lines of SQL&#8230;literally. It would be fine if Active Record works well with most schemas or all schemas a particular developer has but that just isn&#8217;t the case. It works well most of the time but seems to fail at least somewhere in a project.</p>
<p>SQL is a very high-level but still flexible API for working with stored data. Active Record is a high-level, less flexible API for working with stored data. Perhaps the ORM experiment failed and the RDMBS experiment won? I&#8217;m thinking about going back to straight SQL.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kriszyp</title>
		<link>http://ajaxian.com/archives/what-is-the-future-of-ajax-applications-talking-to-the-data-tier/comment-page-1#comment-262986</link>
		<dc:creator>kriszyp</dc:creator>
		<pubDate>Mon, 21 Apr 2008 14:35:21 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=3572#comment-262986</guid>
		<description>As far as databases for the web, I really think &lt;a href=&quot;http://code.google.com/p/persevere-framework/&quot; rel=&quot;nofollow&quot;&gt;Persevere&lt;/a&gt; is worthy to be mentioned as well. DBs like CouchDB and Amazon&#039;s S3 are not really safe to use directly from web clients/Ajax, since they don&#039;t have the necessary security model, they are more intended to be used from the backend. Persevere can be used by Ajax, and Persevere also can integrate existing SQL tables, and make them available through RESTful HTTP/JSON, with JSONPath queries, and SSJS as well.</description>
		<content:encoded><![CDATA[<p>As far as databases for the web, I really think <a href="http://code.google.com/p/persevere-framework/" rel="nofollow">Persevere</a> is worthy to be mentioned as well. DBs like CouchDB and Amazon&#8217;s S3 are not really safe to use directly from web clients/Ajax, since they don&#8217;t have the necessary security model, they are more intended to be used from the backend. Persevere can be used by Ajax, and Persevere also can integrate existing SQL tables, and make them available through RESTful HTTP/JSON, with JSONPath queries, and SSJS as well.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
