<?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"
	>
<channel>
	<title>Comments on: The 4 main approaches to datatype extensibility</title>
	<atom:link href="http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/</link>
	<description>Choices in data management and analysis</description>
	<pubDate>Fri, 16 May 2008 07:40:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74927</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Wed, 27 Feb 2008 20:08:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74927</guid>
		<description>Ning,

The answer to most of your questions is "I don't know."

That said, Cogito definitely was supporting graphs and not just trees.  Whether they optimized clustering for general graphs or just for trees is of course a whole other matter, since the former is a much harder problem.

As I write this, either my calendar is wrong or the CEO of the successor company is late giving me a phone call. As I said -- stay tuned.;)

EDIT:  Oops. I was supposed to call him, not vice-versa ...

CAM</description>
		<content:encoded><![CDATA[<p>Ning,</p>
<p>The answer to most of your questions is &#8220;I don&#8217;t know.&#8221;</p>
<p>That said, Cogito definitely was supporting graphs and not just trees.  Whether they optimized clustering for general graphs or just for trees is of course a whole other matter, since the former is a much harder problem.</p>
<p>As I write this, either my calendar is wrong or the CEO of the successor company is late giving me a phone call. As I said &#8212; stay tuned.;)</p>
<p>EDIT:  Oops. I was supposed to call him, not vice-versa &#8230;</p>
<p>CAM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ning Zhang</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74814</link>
		<dc:creator>Ning Zhang</dc:creator>
		<pubDate>Wed, 27 Feb 2008 06:20:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74814</guid>
		<description>Curt, 

Thanks for the pointers. I've read your Cogito white paper and their web site. Although there is not much detail about the GQL, storage and query processing, it seems a more interesting approach comparing to some of the relational approaches developed for graph databases -- one simple reason is because SQL is not expressive enough to specify complex graph queries. Also clustering nodes based on their proximity is also more promising than set-oriented storage. Graph partitioning techniques seems to be one of the keys to the performance.

Some technical questions about the MyFamily.com example mentioned in your white paper. Are there any details about the experiments? i.e., is the database RAM-based/disk-based? Are there any indexes? is the data set really a graph or a tree (seems tree is enough for the problem)? 

I looking forward to your update.

Thanks,
Ning</description>
		<content:encoded><![CDATA[<p>Curt, </p>
<p>Thanks for the pointers. I&#8217;ve read your Cogito white paper and their web site. Although there is not much detail about the GQL, storage and query processing, it seems a more interesting approach comparing to some of the relational approaches developed for graph databases &#8212; one simple reason is because SQL is not expressive enough to specify complex graph queries. Also clustering nodes based on their proximity is also more promising than set-oriented storage. Graph partitioning techniques seems to be one of the keys to the performance.</p>
<p>Some technical questions about the MyFamily.com example mentioned in your white paper. Are there any details about the experiments? i.e., is the database RAM-based/disk-based? Are there any indexes? is the data set really a graph or a tree (seems tree is enough for the problem)? </p>
<p>I looking forward to your update.</p>
<p>Thanks,<br />
Ning</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74789</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Wed, 27 Feb 2008 04:21:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74789</guid>
		<description>Ning,

Cogito had an interesting approach to graphs, which I wrote about here.  Its assets have no been bought by another company; stay tuned.

RDF is the other approach to graphs, of course.  If you look at the RDF section here, you may find some thoughts congenial with yours. :)

CAM</description>
		<content:encoded><![CDATA[<p>Ning,</p>
<p>Cogito had an interesting approach to graphs, which I wrote about here.  Its assets have no been bought by another company; stay tuned.</p>
<p>RDF is the other approach to graphs, of course.  If you look at the RDF section here, you may find some thoughts congenial with yours. <img src='http://www.dbms2.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>CAM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ning Zhang</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74780</link>
		<dc:creator>Ning Zhang</dc:creator>
		<pubDate>Wed, 27 Feb 2008 03:05:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-74780</guid>
		<description>Curt,

Great post and very informative about the big picture! Having been studying and working on XML databases for more than 5 years, I've seen good and bad usages of XML. In my personally opinion, the best thing about XML is that it doesn't require a schema or it could define a very flexible schema, yet you can define relational views on top of it to "map" it to some schema. This saves a lot of headaches from schema evolutionand data/schema integration.

Also regarding to data types or data models, I thik graph data model and graph querylanguages may play a significant role in the future database research and development. There are many applications that can be naturally modeled as a database problem ongraphs (examples include social networks, scientific data, and RDF). Queries (e.g., route queries) on graphs are usually not expressible in pure SQL. Using vendor-dependent extensions or UDFs usually results in unacceptable performance on large data sets. So I guess graphs should be the next data type that major DBMS vendors should support in the near future.

Thanks,
Ning

Ning</description>
		<content:encoded><![CDATA[<p>Curt,</p>
<p>Great post and very informative about the big picture! Having been studying and working on XML databases for more than 5 years, I&#8217;ve seen good and bad usages of XML. In my personally opinion, the best thing about XML is that it doesn&#8217;t require a schema or it could define a very flexible schema, yet you can define relational views on top of it to &#8220;map&#8221; it to some schema. This saves a lot of headaches from schema evolutionand data/schema integration.</p>
<p>Also regarding to data types or data models, I thik graph data model and graph querylanguages may play a significant role in the future database research and development. There are many applications that can be naturally modeled as a database problem ongraphs (examples include social networks, scientific data, and RDF). Queries (e.g., route queries) on graphs are usually not expressible in pure SQL. Using vendor-dependent extensions or UDFs usually results in unacceptable performance on large data sets. So I guess graphs should be the next data type that major DBMS vendors should support in the near future.</p>
<p>Thanks,<br />
Ning</p>
<p>Ning</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69426</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Sun, 27 Jan 2008 22:11:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69426</guid>
		<description>Roland,

I'll respond to the one on-topic thing you've said in this comment thread.  I would guess strongly that the photos at Fotolog.com aren't indexed directly.  E.g., there's no search that says "Show me all the photos with 3 or more faces." (I'd be fascinated if this is wrong, by the way.) Rather, they most likely are indexed on the metadata, such as descriptions. (Nothing wrong with that; image indexing is still pretty primitive.  But it illustrates my point.) I further note that there's no native search of the descriptive text; they just use Google.  (Nothing wrong with that either; I do it too.)

Thus, Fotolog does not appear to be evidence that MySQL is being used to store anything but alphanumeric data and BLOBs/CLOBs. 

As for the off-topic stuff -- we agree on one thing.  There are plenty of other posts and comment threads, here and elsewhere, where the various opinions are noted.

CAM</description>
		<content:encoded><![CDATA[<p>Roland,</p>
<p>I&#8217;ll respond to the one on-topic thing you&#8217;ve said in this comment thread.  I would guess strongly that the photos at Fotolog.com aren&#8217;t indexed directly.  E.g., there&#8217;s no search that says &#8220;Show me all the photos with 3 or more faces.&#8221; (I&#8217;d be fascinated if this is wrong, by the way.) Rather, they most likely are indexed on the metadata, such as descriptions. (Nothing wrong with that; image indexing is still pretty primitive.  But it illustrates my point.) I further note that there&#8217;s no native search of the descriptive text; they just use Google.  (Nothing wrong with that either; I do it too.)</p>
<p>Thus, Fotolog does not appear to be evidence that MySQL is being used to store anything but alphanumeric data and BLOBs/CLOBs. </p>
<p>As for the off-topic stuff &#8212; we agree on one thing.  There are plenty of other posts and comment threads, here and elsewhere, where the various opinions are noted.</p>
<p>CAM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DBNews 2007 #3 &#124; PettiNix</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69385</link>
		<dc:creator>DBNews 2007 #3 &#124; PettiNix</dc:creator>
		<pubDate>Sun, 27 Jan 2008 18:04:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69385</guid>
		<description>[...] di articoli apparsi sulla rete ne voglio evidenziare due di DBMS2, il primo riguardante i 4 approcci  principali all&#8217;estensibilità dei tipi di dati, il secondo invece elenca 14 motivi per cui non dovrebbe essere utilizzato un DBMS di fascia [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] di articoli apparsi sulla rete ne voglio evidenziare due di DBMS2, il primo riguardante i 4 approcci  principali all&#8217;estensibilità dei tipi di dati, il secondo invece elenca 14 motivi per cui non dovrebbe essere utilizzato un DBMS di fascia [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roland Bouman</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69377</link>
		<dc:creator>Roland Bouman</dc:creator>
		<pubDate>Sun, 27 Jan 2008 17:13:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69377</guid>
		<description>"This post was in part for you, because you’d expressed ignorance on the matter of datatypes."

Then thank you so much for enlightening me and the rest of us ignoramuses! I'm so glad you told us all about those fancy datatypes like images, I really should notify Frank Mash at fotolog immediately he must look out for another database that can handle them a.s.ap. 

"the words “slander” and “disgusting” are indeed flames"

What can you expect? You started a smoke screen, it's just natural that there must be a fire somewhere.

"And you’re way out of line for claiming that your statements of opinion are factual at all, let alone that they point out somebody else’s “factual mistakes.”"

I and others have explained exactly and repeatedly where the factual mistakes are. You have been avoiding even an acknowledgement that you are aware the refutations exist, even though you have been given the pointers (and members of posterity can browse the past week of planetmysql.org archives to check for themselves). I'm really starting to believe you are doing this on purpose. 

"Unless you settle down and start thinking clearly, I have no interest in attempting substantive discussion with you."

Oh no...please don't threaten me...does "thinking clearly" mean I can't contradict you anymore? If so, that's really going to be such a tough choice...oh the wretched dilemma!...am I really going to cut myself off of this world-class opportunity to have Curt attempt a substantive discussion with mere me?</description>
		<content:encoded><![CDATA[<p>&#8220;This post was in part for you, because you’d expressed ignorance on the matter of datatypes.&#8221;</p>
<p>Then thank you so much for enlightening me and the rest of us ignoramuses! I&#8217;m so glad you told us all about those fancy datatypes like images, I really should notify Frank Mash at fotolog immediately he must look out for another database that can handle them a.s.ap. </p>
<p>&#8220;the words “slander” and “disgusting” are indeed flames&#8221;</p>
<p>What can you expect? You started a smoke screen, it&#8217;s just natural that there must be a fire somewhere.</p>
<p>&#8220;And you’re way out of line for claiming that your statements of opinion are factual at all, let alone that they point out somebody else’s “factual mistakes.”&#8221;</p>
<p>I and others have explained exactly and repeatedly where the factual mistakes are. You have been avoiding even an acknowledgement that you are aware the refutations exist, even though you have been given the pointers (and members of posterity can browse the past week of planetmysql.org archives to check for themselves). I&#8217;m really starting to believe you are doing this on purpose. </p>
<p>&#8220;Unless you settle down and start thinking clearly, I have no interest in attempting substantive discussion with you.&#8221;</p>
<p>Oh no&#8230;please don&#8217;t threaten me&#8230;does &#8220;thinking clearly&#8221; mean I can&#8217;t contradict you anymore? If so, that&#8217;s really going to be such a tough choice&#8230;oh the wretched dilemma!&#8230;am I really going to cut myself off of this world-class opportunity to have Curt attempt a substantive discussion with mere me?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Curt Monash</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69338</link>
		<dc:creator>Curt Monash</dc:creator>
		<pubDate>Sun, 27 Jan 2008 08:57:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69338</guid>
		<description>Why, thank you for showing up!  This post was in part for you, because you'd expressed ignorance on the matter of datatypes.

Otherwise -- the words "slander" and "disgusting" are indeed flames. And you're way out of line for claiming that your statements of opinion are factual at all, let alone that they point out somebody else's "factual mistakes."

Unless you settle down and start thinking clearly, I have no interest in attempting substantive discussion with you.

CAM</description>
		<content:encoded><![CDATA[<p>Why, thank you for showing up!  This post was in part for you, because you&#8217;d expressed ignorance on the matter of datatypes.</p>
<p>Otherwise &#8212; the words &#8220;slander&#8221; and &#8220;disgusting&#8221; are indeed flames. And you&#8217;re way out of line for claiming that your statements of opinion are factual at all, let alone that they point out somebody else&#8217;s &#8220;factual mistakes.&#8221;</p>
<p>Unless you settle down and start thinking clearly, I have no interest in attempting substantive discussion with you.</p>
<p>CAM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roland Bouman</title>
		<link>http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69335</link>
		<dc:creator>Roland Bouman</dc:creator>
		<pubDate>Sun, 27 Jan 2008 08:33:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbms2.com/2008/01/27/the-4-main-approaches-to-datatype-extensibility/#comment-69335</guid>
		<description>"including some of the flames about my recent confession that mid-range DBMS aren’t suitable for everything"

You confuse "being contradicted" with "being flamed". Instead of being so touchy, you could just show some responsibility and correct the factual mistakes in the post you are referring to.</description>
		<content:encoded><![CDATA[<p>&#8220;including some of the flames about my recent confession that mid-range DBMS aren’t suitable for everything&#8221;</p>
<p>You confuse &#8220;being contradicted&#8221; with &#8220;being flamed&#8221;. Instead of being so touchy, you could just show some responsibility and correct the factual mistakes in the post you are referring to.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
