<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_07_02_219247</id>
	<title>Enthusiasts Convene To Say No To SQL, Hash Out New DB Breed</title>
	<author>timothy</author>
	<datestamp>1246528560000</datestamp>
	<htmltext><a href="http://www.computerworld.com/" rel="nofollow">ericatcw</a> writes <i>"The <a href="http://blog.oskarsson.nu/2009/06/nosql-debrief.html">inaugural NoSQL meet-up</a> in San Francisco during last month's <a href="http://developer.yahoo.com/events/hadoopsummit09/">Yahoo! Apache Hadoop Summit</a> had a whiff of revolution about it, like a latter-day techie version of the American Patriots planning the Boston Tea Party.

Like the Patriots, who rebelled against Britain's heavy taxes, NoSQLers came to share how <a href="http://www.computerworld.com/action/article.do?command=viewArticleBasic&amp;articleId=9135086">they had overthrown the tyranny of burdensome, expensive relational databases</a> in favor of more efficient and cheaper ways of managing data, reports Computerworld."</i></htmltext>
<tokenext>ericatcw writes " The inaugural NoSQL meet-up in San Francisco during last month 's Yahoo !
Apache Hadoop Summit had a whiff of revolution about it , like a latter-day techie version of the American Patriots planning the Boston Tea Party .
Like the Patriots , who rebelled against Britain 's heavy taxes , NoSQLers came to share how they had overthrown the tyranny of burdensome , expensive relational databases in favor of more efficient and cheaper ways of managing data , reports Computerworld .
"</tokentext>
<sentencetext>ericatcw writes "The inaugural NoSQL meet-up in San Francisco during last month's Yahoo!
Apache Hadoop Summit had a whiff of revolution about it, like a latter-day techie version of the American Patriots planning the Boston Tea Party.
Like the Patriots, who rebelled against Britain's heavy taxes, NoSQLers came to share how they had overthrown the tyranny of burdensome, expensive relational databases in favor of more efficient and cheaper ways of managing data, reports Computerworld.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565289</id>
	<title>The problem is performance not SQL</title>
	<author>presidenteloco</author>
	<datestamp>1246533240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>The problem is the performance of transactions and persistence and distribution of data techniques, not<br>whether we are using a logic-like STRUCTURED QUERY LANGUAGE to ask for data matching certain conditions.</p><p>The latter is still, and will continue to be, very useful.</p><p>It's just that now that we can assume local clusters and WANs worth of co-operating data stores, there<br>are probably better, more performant ways of implementing persistence, replication, distribution of data<br>than traditional RDBMS implementations.</p><p>The two concerns: The logical model of how we QUERY for data (or combine it in bulk), which is the core of SQL,<br>and how we persist it and retrieve it quickly, now have more options for being separated.<br>
&nbsp;</p></htmltext>
<tokenext>The problem is the performance of transactions and persistence and distribution of data techniques , notwhether we are using a logic-like STRUCTURED QUERY LANGUAGE to ask for data matching certain conditions.The latter is still , and will continue to be , very useful.It 's just that now that we can assume local clusters and WANs worth of co-operating data stores , thereare probably better , more performant ways of implementing persistence , replication , distribution of datathan traditional RDBMS implementations.The two concerns : The logical model of how we QUERY for data ( or combine it in bulk ) , which is the core of SQL,and how we persist it and retrieve it quickly , now have more options for being separated .
 </tokentext>
<sentencetext>The problem is the performance of transactions and persistence and distribution of data techniques, notwhether we are using a logic-like STRUCTURED QUERY LANGUAGE to ask for data matching certain conditions.The latter is still, and will continue to be, very useful.It's just that now that we can assume local clusters and WANs worth of co-operating data stores, thereare probably better, more performant ways of implementing persistence, replication, distribution of datathan traditional RDBMS implementations.The two concerns: The logical model of how we QUERY for data (or combine it in bulk), which is the core of SQL,and how we persist it and retrieve it quickly, now have more options for being separated.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568119</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246553520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We were just talking about this at work today.  I believe that the disconnect between SQL and domain objects comes from the different ways to model data available now.  For example, if you define your data with XML first, you can easily add more features than a database can handle.  The simple example that seems to keep popping up at work is inheritance.  You create a Shape base class, then extend it with Point, Circle, Polygon, etc. etc.  Logical, object-oriented and totally allowed in XML.  However, putting it into a database is a mess.  You wind up with a parent Point table, a type, and then a set of child tables, one of which is populated.  (If there's a better way to do this, let me know).</p><p>So the only way to create a useable database schema is to create that first, and work around the limitations in the relational table model.  Otherwise, you will wind up jumping through hoops of your own creation.  And I think that's what this group is up to:  allowing persistence of arbitrary objects, defined and created agnostically of the storage mechanism.</p></htmltext>
<tokenext>We were just talking about this at work today .
I believe that the disconnect between SQL and domain objects comes from the different ways to model data available now .
For example , if you define your data with XML first , you can easily add more features than a database can handle .
The simple example that seems to keep popping up at work is inheritance .
You create a Shape base class , then extend it with Point , Circle , Polygon , etc .
etc. Logical , object-oriented and totally allowed in XML .
However , putting it into a database is a mess .
You wind up with a parent Point table , a type , and then a set of child tables , one of which is populated .
( If there 's a better way to do this , let me know ) .So the only way to create a useable database schema is to create that first , and work around the limitations in the relational table model .
Otherwise , you will wind up jumping through hoops of your own creation .
And I think that 's what this group is up to : allowing persistence of arbitrary objects , defined and created agnostically of the storage mechanism .</tokentext>
<sentencetext>We were just talking about this at work today.
I believe that the disconnect between SQL and domain objects comes from the different ways to model data available now.
For example, if you define your data with XML first, you can easily add more features than a database can handle.
The simple example that seems to keep popping up at work is inheritance.
You create a Shape base class, then extend it with Point, Circle, Polygon, etc.
etc.  Logical, object-oriented and totally allowed in XML.
However, putting it into a database is a mess.
You wind up with a parent Point table, a type, and then a set of child tables, one of which is populated.
(If there's a better way to do this, let me know).So the only way to create a useable database schema is to create that first, and work around the limitations in the relational table model.
Otherwise, you will wind up jumping through hoops of your own creation.
And I think that's what this group is up to:  allowing persistence of arbitrary objects, defined and created agnostically of the storage mechanism.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571511</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246635060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Damn you!</p><p>I'm a Java developer, one who actually studied computer science, and I not only ADORE SQL, I use it every day at work.  Java's SQL support is better than any other language I've used, and using my objects with an Oracle database (or JavaDB embedded database, which I use in my main project) is a piece of cake.</p><p>
&nbsp; Good Java programmers LOVE SQL, because the process of entity-relationship modeling can be run in parallel to (and coordinated with) the process of object modeling. If you're any damn GOOD, the two processes go hand in hand, and mirror each other.</p><p>Object to RDBMS mapping is as easy as writing insert, update, fetch and delete methods in your objects. If you want to make your objects fully extensible, all you have to do is put most of your database code in an abstract base class, and provide abstract methods for setting SQL and assigning bind variables, and let your child classes implement them.  It's not rocket science, it's not even difficult.</p><p>Don't you DARE lump us Java guys in with the PhP degenerates!  You fool! You dilettante!</p><p>You... PHP CODER!</p></htmltext>
<tokenext>Damn you ! I 'm a Java developer , one who actually studied computer science , and I not only ADORE SQL , I use it every day at work .
Java 's SQL support is better than any other language I 've used , and using my objects with an Oracle database ( or JavaDB embedded database , which I use in my main project ) is a piece of cake .
  Good Java programmers LOVE SQL , because the process of entity-relationship modeling can be run in parallel to ( and coordinated with ) the process of object modeling .
If you 're any damn GOOD , the two processes go hand in hand , and mirror each other.Object to RDBMS mapping is as easy as writing insert , update , fetch and delete methods in your objects .
If you want to make your objects fully extensible , all you have to do is put most of your database code in an abstract base class , and provide abstract methods for setting SQL and assigning bind variables , and let your child classes implement them .
It 's not rocket science , it 's not even difficult.Do n't you DARE lump us Java guys in with the PhP degenerates !
You fool !
You dilettante ! You... PHP CODER !</tokentext>
<sentencetext>Damn you!I'm a Java developer, one who actually studied computer science, and I not only ADORE SQL, I use it every day at work.
Java's SQL support is better than any other language I've used, and using my objects with an Oracle database (or JavaDB embedded database, which I use in my main project) is a piece of cake.
  Good Java programmers LOVE SQL, because the process of entity-relationship modeling can be run in parallel to (and coordinated with) the process of object modeling.
If you're any damn GOOD, the two processes go hand in hand, and mirror each other.Object to RDBMS mapping is as easy as writing insert, update, fetch and delete methods in your objects.
If you want to make your objects fully extensible, all you have to do is put most of your database code in an abstract base class, and provide abstract methods for setting SQL and assigning bind variables, and let your child classes implement them.
It's not rocket science, it's not even difficult.Don't you DARE lump us Java guys in with the PhP degenerates!
You fool!
You dilettante!You... PHP CODER!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568343</id>
	<title>Re:A time and place for everything</title>
	<author>cheekyboy</author>
	<datestamp>1246555800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I would love to some create a massive SQL query which can decode mpeg4 video.<br>Yes its a wrong language for the problem, but decoding compressed video is a BIG data manipulation problem.</p><p>I guess what people are saying is that sure SQL might do its job, but it has some arcane stupid syntaxes that look like cobol. The differences between each commercial/OS vendor are large enough as to be anoying.</p><p>What people are looking for is a common language that is vendor neutral, and more modern looking. I guess kind of like OpenGL or DX10, some api/lang set that runs via a driver to the final DB solution. So the database is like a graphics card, separated from the api/language. So its easy to swap vendors.</p><p>This is the key that sucks with SQL, once you commit to one vendor, its hard to escape. Today we have OS nuetral 3d apis, window apis, network apis, sound apis. A truely layered DB api/lang that isnt locked to stone to the vendor? No chance.</p></htmltext>
<tokenext>I would love to some create a massive SQL query which can decode mpeg4 video.Yes its a wrong language for the problem , but decoding compressed video is a BIG data manipulation problem.I guess what people are saying is that sure SQL might do its job , but it has some arcane stupid syntaxes that look like cobol .
The differences between each commercial/OS vendor are large enough as to be anoying.What people are looking for is a common language that is vendor neutral , and more modern looking .
I guess kind of like OpenGL or DX10 , some api/lang set that runs via a driver to the final DB solution .
So the database is like a graphics card , separated from the api/language .
So its easy to swap vendors.This is the key that sucks with SQL , once you commit to one vendor , its hard to escape .
Today we have OS nuetral 3d apis , window apis , network apis , sound apis .
A truely layered DB api/lang that isnt locked to stone to the vendor ?
No chance .</tokentext>
<sentencetext>I would love to some create a massive SQL query which can decode mpeg4 video.Yes its a wrong language for the problem, but decoding compressed video is a BIG data manipulation problem.I guess what people are saying is that sure SQL might do its job, but it has some arcane stupid syntaxes that look like cobol.
The differences between each commercial/OS vendor are large enough as to be anoying.What people are looking for is a common language that is vendor neutral, and more modern looking.
I guess kind of like OpenGL or DX10, some api/lang set that runs via a driver to the final DB solution.
So the database is like a graphics card, separated from the api/language.
So its easy to swap vendors.This is the key that sucks with SQL, once you commit to one vendor, its hard to escape.
Today we have OS nuetral 3d apis, window apis, network apis, sound apis.
A truely layered DB api/lang that isnt locked to stone to the vendor?
No chance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567501</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246547700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>*Nothing* except the most trivial select  from  group by  is simple in SQL (granted, this is already a bit on the complex side, but still).</p><p>The reason for this is simple.</p><p>You cannot assign a select to a "variable" to be reused several times, so anything even remotely complex degenerates into a massive cut and paste or programmed repetition that more often than not fails due to the idiotic column-name-must-be-unique-in-the-whole-schema-or-else b***shit.</p><p>Anyway.</p><p>SQL blows. Ever tried to compare an IDE from the early 1990s with current SQL "development environments"? That's right, Turbo Pascal 4.0 was better. Why? SQL is unparseable. Even if the vendors could agree on a non-useless subset to support (since even sequences are out, I'm not holding my breath), the language itself is not parseable by any modern language development tool (lex, yacc, javacc, whatever). Yeah, "modern" in that context means anything written since the mid 70s.</p><p>The relational model is cr*p. Well, my bad, it's good the same way democracy is. Everything else is worse. The fact of the matter is that every project designed in the past 10 years includes *some* concept of inheritance, and SQL has good way to handle such a simple thing. You can have a wide table, and constraints are right out (which is half of what databases arer good for IMHO), or you have several tables, which duplicate a lot, and transform a single select into a mess. Yet you get the 3rd manifesto guys explaining that the problem is that SQL didn't do relational right. A model is a *model*  for crying out loud! It tells you what a system can and cannot do, that's it. I can't hear anyone saying we should program in brainfuck because that's "The Turing Model". Can you?</p><p>I don't personally agree with this whole noSQL thing, because the first thing they do is tossing out transactions, and that's the most important thing. I don't care about SQL, I don't care about the language, ot the model, I might accept checking constraints, foreign keys even in the app layer, but not transactions.</p><p>Cheers.</p></htmltext>
<tokenext>* Nothing * except the most trivial select from group by is simple in SQL ( granted , this is already a bit on the complex side , but still ) .The reason for this is simple.You can not assign a select to a " variable " to be reused several times , so anything even remotely complex degenerates into a massive cut and paste or programmed repetition that more often than not fails due to the idiotic column-name-must-be-unique-in-the-whole-schema-or-else b * * * shit.Anyway.SQL blows .
Ever tried to compare an IDE from the early 1990s with current SQL " development environments " ?
That 's right , Turbo Pascal 4.0 was better .
Why ? SQL is unparseable .
Even if the vendors could agree on a non-useless subset to support ( since even sequences are out , I 'm not holding my breath ) , the language itself is not parseable by any modern language development tool ( lex , yacc , javacc , whatever ) .
Yeah , " modern " in that context means anything written since the mid 70s.The relational model is cr * p. Well , my bad , it 's good the same way democracy is .
Everything else is worse .
The fact of the matter is that every project designed in the past 10 years includes * some * concept of inheritance , and SQL has good way to handle such a simple thing .
You can have a wide table , and constraints are right out ( which is half of what databases arer good for IMHO ) , or you have several tables , which duplicate a lot , and transform a single select into a mess .
Yet you get the 3rd manifesto guys explaining that the problem is that SQL did n't do relational right .
A model is a * model * for crying out loud !
It tells you what a system can and can not do , that 's it .
I ca n't hear anyone saying we should program in brainfuck because that 's " The Turing Model " .
Can you ? I do n't personally agree with this whole noSQL thing , because the first thing they do is tossing out transactions , and that 's the most important thing .
I do n't care about SQL , I do n't care about the language , ot the model , I might accept checking constraints , foreign keys even in the app layer , but not transactions.Cheers .</tokentext>
<sentencetext>*Nothing* except the most trivial select  from  group by  is simple in SQL (granted, this is already a bit on the complex side, but still).The reason for this is simple.You cannot assign a select to a "variable" to be reused several times, so anything even remotely complex degenerates into a massive cut and paste or programmed repetition that more often than not fails due to the idiotic column-name-must-be-unique-in-the-whole-schema-or-else b***shit.Anyway.SQL blows.
Ever tried to compare an IDE from the early 1990s with current SQL "development environments"?
That's right, Turbo Pascal 4.0 was better.
Why? SQL is unparseable.
Even if the vendors could agree on a non-useless subset to support (since even sequences are out, I'm not holding my breath), the language itself is not parseable by any modern language development tool (lex, yacc, javacc, whatever).
Yeah, "modern" in that context means anything written since the mid 70s.The relational model is cr*p. Well, my bad, it's good the same way democracy is.
Everything else is worse.
The fact of the matter is that every project designed in the past 10 years includes *some* concept of inheritance, and SQL has good way to handle such a simple thing.
You can have a wide table, and constraints are right out (which is half of what databases arer good for IMHO), or you have several tables, which duplicate a lot, and transform a single select into a mess.
Yet you get the 3rd manifesto guys explaining that the problem is that SQL didn't do relational right.
A model is a *model*  for crying out loud!
It tells you what a system can and cannot do, that's it.
I can't hear anyone saying we should program in brainfuck because that's "The Turing Model".
Can you?I don't personally agree with this whole noSQL thing, because the first thing they do is tossing out transactions, and that's the most important thing.
I don't care about SQL, I don't care about the language, ot the model, I might accept checking constraints, foreign keys even in the app layer, but not transactions.Cheers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565955</id>
	<title>Re:The problem is performance not SQL</title>
	<author>Anonymous</author>
	<datestamp>1246537020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>It's just that now that we can assume local clusters and WANs worth of co-operating data stores, there
are probably better, more performant ways of implementing persistence, replication, distribution of data
than traditional RDBMS implementations.</p></div><p>You can also assume magical fairy dust and free energy, but that doesn't make it so.  You can <i>ask</i> if there are better ways, but you can't <i>assume</i> it, and in the end you will find <b>there is no magic</b>.</p><p>Clusters and replication are NOT NEW.  Not even remotely new.  There is, in fact, nothing new architecturally at <i>all</i> that would indicate some new capability that hasn't already been repeatedly analyzed and tried.  That doesn't mean you can't tweak something for a situation, or that you need a giant Oracle database for everything, but "the web" and "cheap hardware" change the equation by precisely nothing.</p><p>What has changed the equation is <i>cheap, unimportant data,</i> which covers the majority of the web.  "Real" applications, where data integrity is important (like say, your bank account), and immediate accuracy guaranteed, require the <i>main</i> thing you use a database for: data integrity.  Your facebook page, your google search, that blog entry, or some video on youtube: these don't matter.  If it's a little slow, or doesn't update immediately, or you get an error, no one is losing money.  No one cares.</p><p>In essence, if a reliable database isn't important for your app, your app isn't really handling important data.  This may be fine; in the mainstream, there's a lot of noncritical stuff.  But this doesn't make databases unimportant.</p></div>
	</htmltext>
<tokenext>It 's just that now that we can assume local clusters and WANs worth of co-operating data stores , there are probably better , more performant ways of implementing persistence , replication , distribution of data than traditional RDBMS implementations.You can also assume magical fairy dust and free energy , but that does n't make it so .
You can ask if there are better ways , but you ca n't assume it , and in the end you will find there is no magic.Clusters and replication are NOT NEW .
Not even remotely new .
There is , in fact , nothing new architecturally at all that would indicate some new capability that has n't already been repeatedly analyzed and tried .
That does n't mean you ca n't tweak something for a situation , or that you need a giant Oracle database for everything , but " the web " and " cheap hardware " change the equation by precisely nothing.What has changed the equation is cheap , unimportant data , which covers the majority of the web .
" Real " applications , where data integrity is important ( like say , your bank account ) , and immediate accuracy guaranteed , require the main thing you use a database for : data integrity .
Your facebook page , your google search , that blog entry , or some video on youtube : these do n't matter .
If it 's a little slow , or does n't update immediately , or you get an error , no one is losing money .
No one cares.In essence , if a reliable database is n't important for your app , your app is n't really handling important data .
This may be fine ; in the mainstream , there 's a lot of noncritical stuff .
But this does n't make databases unimportant .</tokentext>
<sentencetext>It's just that now that we can assume local clusters and WANs worth of co-operating data stores, there
are probably better, more performant ways of implementing persistence, replication, distribution of data
than traditional RDBMS implementations.You can also assume magical fairy dust and free energy, but that doesn't make it so.
You can ask if there are better ways, but you can't assume it, and in the end you will find there is no magic.Clusters and replication are NOT NEW.
Not even remotely new.
There is, in fact, nothing new architecturally at all that would indicate some new capability that hasn't already been repeatedly analyzed and tried.
That doesn't mean you can't tweak something for a situation, or that you need a giant Oracle database for everything, but "the web" and "cheap hardware" change the equation by precisely nothing.What has changed the equation is cheap, unimportant data, which covers the majority of the web.
"Real" applications, where data integrity is important (like say, your bank account), and immediate accuracy guaranteed, require the main thing you use a database for: data integrity.
Your facebook page, your google search, that blog entry, or some video on youtube: these don't matter.
If it's a little slow, or doesn't update immediately, or you get an error, no one is losing money.
No one cares.In essence, if a reliable database isn't important for your app, your app isn't really handling important data.
This may be fine; in the mainstream, there's a lot of noncritical stuff.
But this doesn't make databases unimportant.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565289</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569891</id>
	<title>Tree structures in relational</title>
	<author>JerryQ</author>
	<datestamp>1246620300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I do it all the time,<br> <br>

I add a string key, e.g., AAA\_BBB\_CCC\_DDD..... and alpha index it<br> <br>

To find all the offspring of AAA\_BBB\_CCC look for like 'AAA\_BBB\_CCC*'<br> <br>

To find all the siblings of AAA\_BBB\_CCC look for like 'AAA\_BBB\_\%\%\%' where \% is a single char wildcard.</htmltext>
<tokenext>I do it all the time , I add a string key , e.g. , AAA \ _BBB \ _CCC \ _DDD..... and alpha index it To find all the offspring of AAA \ _BBB \ _CCC look for like 'AAA \ _BBB \ _CCC * ' To find all the siblings of AAA \ _BBB \ _CCC look for like 'AAA \ _BBB \ _ \ % \ % \ % ' where \ % is a single char wildcard .</tokentext>
<sentencetext>I do it all the time, 

I add a string key, e.g., AAA\_BBB\_CCC\_DDD..... and alpha index it 

To find all the offspring of AAA\_BBB\_CCC look for like 'AAA\_BBB\_CCC*' 

To find all the siblings of AAA\_BBB\_CCC look for like 'AAA\_BBB\_\%\%\%' where \% is a single char wildcard.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572785</id>
	<title>Re:A time and place for everything</title>
	<author>jadavis</author>
	<datestamp>1246642620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>You cannot easily add new fields to a table</i></p><p><a href="http://postgresql.org/" title="postgresql.org">Some database systems</a> [postgresql.org] make this easy.</p><p><i>Migrating large amounts of relational data to a new structure takes a very very long time.</i></p><p>That's true for any large amount of data. Relational data tends to be much more flexible, so this is less important than in, say, a hierarchical database where reorganization is not only incredibly expensive, but may be a prerequisite for even passable performance of some queries.</p><p><i>It's difficult to maintain the data integrity... and have acceptable performance</i></p><p>Again, not specific to relational database systems. It's much more difficult and expensive to maintain data integrity in a hierarchical system unless the constraint and the hierarchy are one and the same.</p></htmltext>
<tokenext>You can not easily add new fields to a tableSome database systems [ postgresql.org ] make this easy.Migrating large amounts of relational data to a new structure takes a very very long time.That 's true for any large amount of data .
Relational data tends to be much more flexible , so this is less important than in , say , a hierarchical database where reorganization is not only incredibly expensive , but may be a prerequisite for even passable performance of some queries.It 's difficult to maintain the data integrity... and have acceptable performanceAgain , not specific to relational database systems .
It 's much more difficult and expensive to maintain data integrity in a hierarchical system unless the constraint and the hierarchy are one and the same .</tokentext>
<sentencetext>You cannot easily add new fields to a tableSome database systems [postgresql.org] make this easy.Migrating large amounts of relational data to a new structure takes a very very long time.That's true for any large amount of data.
Relational data tends to be much more flexible, so this is less important than in, say, a hierarchical database where reorganization is not only incredibly expensive, but may be a prerequisite for even passable performance of some queries.It's difficult to maintain the data integrity... and have acceptable performanceAgain, not specific to relational database systems.
It's much more difficult and expensive to maintain data integrity in a hierarchical system unless the constraint and the hierarchy are one and the same.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571961</id>
	<title>Re:Quit Whining</title>
	<author>jadavis</author>
	<datestamp>1246637580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>But what I'm tired of is people not understanding their data.</i></p><p>I'd agree with that, but it's pretty vague.</p><p>A lot of developers put too much emphasis on the writing of data somewhere, without much emphasis on how they're going to interpret it later amongst some other few million pieces of data. If you store everything as a text blob, that severely limits your searching options.</p></htmltext>
<tokenext>But what I 'm tired of is people not understanding their data.I 'd agree with that , but it 's pretty vague.A lot of developers put too much emphasis on the writing of data somewhere , without much emphasis on how they 're going to interpret it later amongst some other few million pieces of data .
If you store everything as a text blob , that severely limits your searching options .</tokentext>
<sentencetext>But what I'm tired of is people not understanding their data.I'd agree with that, but it's pretty vague.A lot of developers put too much emphasis on the writing of data somewhere, without much emphasis on how they're going to interpret it later amongst some other few million pieces of data.
If you store everything as a text blob, that severely limits your searching options.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701</id>
	<title>Pros &amp; Cons of non-relational solutions</title>
	<author>kpharmer</author>
	<datestamp>1246535640000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>Note that most of these solutions come from the interwebs, social networks, etc.  And it isn't so much anti-sql as it is anti-relational database (sql != rdb).</p><p>The basic premise is that we need different solutions that: can scale very high for very narrowly scoped reads &amp; writes,  don't need to perform ranged queries / reporting<nobr> <wbr></nobr>/etc, and don't need ACID compliance.   And that may be the case.  Sites like slashdot, facebook, reddit, digg, etc don't need the data quality that ebay needs.</p><p>On the other hand, ebay achieves scalability AND data quality with relational databases.   And when I've worked with architectures that scale massively and avoid the relational trap for better solutions - they inevitably later regret the lack of data quality and complete inability to actually get trends and analysis of their data.  It *always* goes like this:<br>
&nbsp; &nbsp; Me:  So, is this thing (msg type, etc) increasing?<br>
&nbsp; &nbsp; Developer:  No idea.<br>
&nbsp; &nbsp; Me: Ok, so lets find out.<br>
&nbsp; &nbsp; Developer:  How?<br>
&nbsp; &nbsp; Me: I don't know - typical approach - lets query the database.<br>
&nbsp; &nbsp; Developer:  It'll take four+ hours to write &amp; test that query and then days to run.  And when it's done we might find that we wrote the query wrong.<br>
&nbsp; &nbsp; Me: What?!?<br>
&nbsp; &nbsp; Developer:  We had to do it this way, you can't report on 10TB databases anyhow<br>
&nbsp; &nbsp; Me: What?!? Are you on crack?  there are dozens of *100TB* relational databases out there that people are reporting on<br>
&nbsp; &nbsp; Developer:  well, we probably don't need to know what that trend is anyhow<br>
&nbsp; &nbsp; Me:  I'm outta here</p></htmltext>
<tokenext>Note that most of these solutions come from the interwebs , social networks , etc .
And it is n't so much anti-sql as it is anti-relational database ( sql ! = rdb ) .The basic premise is that we need different solutions that : can scale very high for very narrowly scoped reads &amp; writes , do n't need to perform ranged queries / reporting /etc , and do n't need ACID compliance .
And that may be the case .
Sites like slashdot , facebook , reddit , digg , etc do n't need the data quality that ebay needs.On the other hand , ebay achieves scalability AND data quality with relational databases .
And when I 've worked with architectures that scale massively and avoid the relational trap for better solutions - they inevitably later regret the lack of data quality and complete inability to actually get trends and analysis of their data .
It * always * goes like this :     Me : So , is this thing ( msg type , etc ) increasing ?
    Developer : No idea .
    Me : Ok , so lets find out .
    Developer : How ?
    Me : I do n't know - typical approach - lets query the database .
    Developer : It 'll take four + hours to write &amp; test that query and then days to run .
And when it 's done we might find that we wrote the query wrong .
    Me : What ? ! ?
    Developer : We had to do it this way , you ca n't report on 10TB databases anyhow     Me : What ? ! ?
Are you on crack ?
there are dozens of * 100TB * relational databases out there that people are reporting on     Developer : well , we probably do n't need to know what that trend is anyhow     Me : I 'm outta here</tokentext>
<sentencetext>Note that most of these solutions come from the interwebs, social networks, etc.
And it isn't so much anti-sql as it is anti-relational database (sql != rdb).The basic premise is that we need different solutions that: can scale very high for very narrowly scoped reads &amp; writes,  don't need to perform ranged queries / reporting /etc, and don't need ACID compliance.
And that may be the case.
Sites like slashdot, facebook, reddit, digg, etc don't need the data quality that ebay needs.On the other hand, ebay achieves scalability AND data quality with relational databases.
And when I've worked with architectures that scale massively and avoid the relational trap for better solutions - they inevitably later regret the lack of data quality and complete inability to actually get trends and analysis of their data.
It *always* goes like this:
    Me:  So, is this thing (msg type, etc) increasing?
    Developer:  No idea.
    Me: Ok, so lets find out.
    Developer:  How?
    Me: I don't know - typical approach - lets query the database.
    Developer:  It'll take four+ hours to write &amp; test that query and then days to run.
And when it's done we might find that we wrote the query wrong.
    Me: What?!?
    Developer:  We had to do it this way, you can't report on 10TB databases anyhow
    Me: What?!?
Are you on crack?
there are dozens of *100TB* relational databases out there that people are reporting on
    Developer:  well, we probably don't need to know what that trend is anyhow
    Me:  I'm outta here</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568849</id>
	<title>Re:Flat Earth</title>
	<author>shutdown -p now</author>
	<datestamp>1246562640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>SQL is actually a pretty damned good, single-purpose language.</p> </div><p>I disagree. SQL is actually a rather crappy language for what it does - unnecessarily verbose, lots of weird corner cases and exceptions, very unobvious solutions to some rather common problems, etc. In comparison, something like Date's language (as implemented in e.g. <a href="http://www.suneido.com/index.php?option=com\_content&amp;task=view&amp;id=49&amp;Itemid=1" title="suneido.com">Suneido</a> [suneido.com]) is far cleaner...</p><p>C is also a crappy language. It has messy grammar, hard both for humans to read and for compilers to parse (a feat oonly surpassed by C++ and Perl), necessitating <a href="http://linux.die.net/man/1/cdecl" title="die.net">tools</a> [die.net] for something that really shouldn't require one. It has some totally unused and pointless features, such as separate namespaces for structs/unions/enums, or the "auto" keyword. It has weird unsigned arithmetic rules. You can write <a href="http://en.wikipedia.org/wiki/Duff's\_device" title="wikipedia.org">code</a> [wikipedia.org] in it that put Perl to shame. Truly, Modula-2 is a far better system programming language...</p><p>But here's the thing. Everyone knows C. There are dozens of compilers, IDEs and associated tools - every platform has one targeting it. There are hundreds of books and thousands of tutorials, and millions of programmers who know it. C API and ABI are de facto standards for reusable libraries and FFI. All this because, really, C is good enough. It may be messy, but it does mostly everything that needs doing. And in areas where it <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf" title="open-std.org">doesn't do so good</a> [open-std.org], it's easier to extend it than reinvent the wheel.</p><p>Same mostly goes for SQL. It's a mammoth spec now, very complicated and not truly implemented by anyone. But the real-world subset works. For all the quirks you have to learn, it does the job, and most SQL skills actually do transfer between implementations. Again, where there are pain points that are just too inconvenient it's easier to extend the language (and, hopefully, eventually <a href="http://en.wikipedia.org/wiki/SQL/XML" title="wikipedia.org">standardize such extensions</a> [wikipedia.org]) than to start from scratch.</p></div>
	</htmltext>
<tokenext>SQL is actually a pretty damned good , single-purpose language .
I disagree .
SQL is actually a rather crappy language for what it does - unnecessarily verbose , lots of weird corner cases and exceptions , very unobvious solutions to some rather common problems , etc .
In comparison , something like Date 's language ( as implemented in e.g .
Suneido [ suneido.com ] ) is far cleaner...C is also a crappy language .
It has messy grammar , hard both for humans to read and for compilers to parse ( a feat oonly surpassed by C + + and Perl ) , necessitating tools [ die.net ] for something that really should n't require one .
It has some totally unused and pointless features , such as separate namespaces for structs/unions/enums , or the " auto " keyword .
It has weird unsigned arithmetic rules .
You can write code [ wikipedia.org ] in it that put Perl to shame .
Truly , Modula-2 is a far better system programming language...But here 's the thing .
Everyone knows C. There are dozens of compilers , IDEs and associated tools - every platform has one targeting it .
There are hundreds of books and thousands of tutorials , and millions of programmers who know it .
C API and ABI are de facto standards for reusable libraries and FFI .
All this because , really , C is good enough .
It may be messy , but it does mostly everything that needs doing .
And in areas where it does n't do so good [ open-std.org ] , it 's easier to extend it than reinvent the wheel.Same mostly goes for SQL .
It 's a mammoth spec now , very complicated and not truly implemented by anyone .
But the real-world subset works .
For all the quirks you have to learn , it does the job , and most SQL skills actually do transfer between implementations .
Again , where there are pain points that are just too inconvenient it 's easier to extend the language ( and , hopefully , eventually standardize such extensions [ wikipedia.org ] ) than to start from scratch .</tokentext>
<sentencetext>SQL is actually a pretty damned good, single-purpose language.
I disagree.
SQL is actually a rather crappy language for what it does - unnecessarily verbose, lots of weird corner cases and exceptions, very unobvious solutions to some rather common problems, etc.
In comparison, something like Date's language (as implemented in e.g.
Suneido [suneido.com]) is far cleaner...C is also a crappy language.
It has messy grammar, hard both for humans to read and for compilers to parse (a feat oonly surpassed by C++ and Perl), necessitating tools [die.net] for something that really shouldn't require one.
It has some totally unused and pointless features, such as separate namespaces for structs/unions/enums, or the "auto" keyword.
It has weird unsigned arithmetic rules.
You can write code [wikipedia.org] in it that put Perl to shame.
Truly, Modula-2 is a far better system programming language...But here's the thing.
Everyone knows C. There are dozens of compilers, IDEs and associated tools - every platform has one targeting it.
There are hundreds of books and thousands of tutorials, and millions of programmers who know it.
C API and ABI are de facto standards for reusable libraries and FFI.
All this because, really, C is good enough.
It may be messy, but it does mostly everything that needs doing.
And in areas where it doesn't do so good [open-std.org], it's easier to extend it than reinvent the wheel.Same mostly goes for SQL.
It's a mammoth spec now, very complicated and not truly implemented by anyone.
But the real-world subset works.
For all the quirks you have to learn, it does the job, and most SQL skills actually do transfer between implementations.
Again, where there are pain points that are just too inconvenient it's easier to extend the language (and, hopefully, eventually standardize such extensions [wikipedia.org]) than to start from scratch.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565345</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28573801</id>
	<title>Re:A time and place for everything</title>
	<author>celtic\_hackr</author>
	<datestamp>1246649100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>Design an efficient table relating a tree structure.</p></div><p>Huh? Tree structures are <i>best</i> handled by relational databases, as it is far faster then recursion. Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.</p></div><p>
Unfortuinately, your solution grows geometrically. Let's take as a sample my family tree, which I've traced, incompletely, to 16 generations. <br>
Number of people in a generation:<br>
my daughter (1),<br>
her parents (2),<br>
her grandparents (4),<br>
gr-grandparents (8),<br><nobr> <wbr></nobr>...<br>
12th gr-grandparents (2^16 ~ 32,000)<br>
Using your algorithm, to find any one of those 12th gr-grandparents, her record would have to have over 16000 left sides and over 16000 right sides creating a solution that grows in time as 2(O(2^(n/2)).<br>
<br>
That is not to say that SQL can't do trees efficiently. For an example of a successful algorithm, you might want to check out the source for PHPGedView ( a genealogy web database app that can use SQL ).</p><p><div class="quote"><p><div class="quote"><p>Then design queries to answer questions such as:
* Find the nodes in the subtree under B.</p></div><p>SELECT * FROM rows WHERE left &gt; [left hand value of B] AND right &lt; [right hand value of B]</p></div><p>
Won't work in your scenario as all the grandchildren of B will have different left hand and right hand values. Or your solution grows in time with O(n^2).</p><p><div class="quote"><p><div class="quote"><p>* Find all ancesters of G</p></div><p>SELECT * FROM rows WHERE left &lt; [left hand value of G] AND right &gt; [right hand value of G]</p></div><p>This is just so wrong, where do I begin.</p><p><div class="quote"><p><div class="quote"><p>* Find the nearest common ancestor of D and H</p></div><p>SELECT * FROM rows WHERE left &lt; [lowest left hand value from D,H] AND right &gt; [highest right hand value from D,H] ORDER BY right LIMIT 1</p></div><p>Still not working.</p><p><div class="quote"><p><div class="quote"><p>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.</p></div><p>Are you saying trees are easy or hard? And for more complex systems, that is what JOINs are for. SQL is by far the most powerful way and often the fastest way to manipulate data that I know of. The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation.</p></div><p>Finding degrees of affinity in genealogy IS a MATRIX operation (or can be one)! It can't be solved by a tree alone. Using a tree philosophy, the fastest solution, would require you to: traverse a person's family relationships, store that result,   traverse the other person's family relationships, then return the relationship with the newest date. Something that can be done very fast in a properly designed SQL dbs [ 2O(log n) + O(log (O(log n))]. Unfortunately, your design isn't one of those I would call properly designed. Of, course, I've oversimplified the problem by ignoring the complexities of the Real World. Such as: adopted children, multiple parents (step parent families), multiple family relationships as a result of cousin marriages, et cetera. It's really a much more complex problem than your simplistic solution would suggest. Which is why it is such an interesting problem.</p></div>
	</htmltext>
<tokenext>Design an efficient table relating a tree structure.Huh ?
Tree structures are best handled by relational databases , as it is far faster then recursion .
Give row a unique ID and a parent ID , and in addition , a left hand and right hand number , the root node having a left-hand value of 1 and a right hand value of ( number rows * 2 ) , the first child node has a left-hand value of one more than the parent 's , the right-hand value is one less then the left-hand of a younger sibling .
Unfortuinately , your solution grows geometrically .
Let 's take as a sample my family tree , which I 've traced , incompletely , to 16 generations .
Number of people in a generation : my daughter ( 1 ) , her parents ( 2 ) , her grandparents ( 4 ) , gr-grandparents ( 8 ) , .. . 12th gr-grandparents ( 2 ^ 16 ~ 32,000 ) Using your algorithm , to find any one of those 12th gr-grandparents , her record would have to have over 16000 left sides and over 16000 right sides creating a solution that grows in time as 2 ( O ( 2 ^ ( n/2 ) ) .
That is not to say that SQL ca n't do trees efficiently .
For an example of a successful algorithm , you might want to check out the source for PHPGedView ( a genealogy web database app that can use SQL ) .Then design queries to answer questions such as : * Find the nodes in the subtree under B.SELECT * FROM rows WHERE left &gt; [ left hand value of B ] AND right Wo n't work in your scenario as all the grandchildren of B will have different left hand and right hand values .
Or your solution grows in time with O ( n ^ 2 ) .
* Find all ancesters of GSELECT * FROM rows WHERE left [ right hand value of G ] This is just so wrong , where do I begin .
* Find the nearest common ancestor of D and HSELECT * FROM rows WHERE left [ highest right hand value from D,H ] ORDER BY right LIMIT 1Still not working.Trees is a wellknown problem of SQL , but the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional ones.Are you saying trees are easy or hard ?
And for more complex systems , that is what JOINs are for .
SQL is by far the most powerful way and often the fastest way to manipulate data that I know of .
The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation.Finding degrees of affinity in genealogy IS a MATRIX operation ( or can be one ) !
It ca n't be solved by a tree alone .
Using a tree philosophy , the fastest solution , would require you to : traverse a person 's family relationships , store that result , traverse the other person 's family relationships , then return the relationship with the newest date .
Something that can be done very fast in a properly designed SQL dbs [ 2O ( log n ) + O ( log ( O ( log n ) ) ] .
Unfortunately , your design is n't one of those I would call properly designed .
Of , course , I 've oversimplified the problem by ignoring the complexities of the Real World .
Such as : adopted children , multiple parents ( step parent families ) , multiple family relationships as a result of cousin marriages , et cetera .
It 's really a much more complex problem than your simplistic solution would suggest .
Which is why it is such an interesting problem .</tokentext>
<sentencetext>Design an efficient table relating a tree structure.Huh?
Tree structures are best handled by relational databases, as it is far faster then recursion.
Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.
Unfortuinately, your solution grows geometrically.
Let's take as a sample my family tree, which I've traced, incompletely, to 16 generations.
Number of people in a generation:
my daughter (1),
her parents (2),
her grandparents (4),
gr-grandparents (8), ...
12th gr-grandparents (2^16 ~ 32,000)
Using your algorithm, to find any one of those 12th gr-grandparents, her record would have to have over 16000 left sides and over 16000 right sides creating a solution that grows in time as 2(O(2^(n/2)).
That is not to say that SQL can't do trees efficiently.
For an example of a successful algorithm, you might want to check out the source for PHPGedView ( a genealogy web database app that can use SQL ).Then design queries to answer questions such as:
* Find the nodes in the subtree under B.SELECT * FROM rows WHERE left &gt; [left hand value of B] AND right 
Won't work in your scenario as all the grandchildren of B will have different left hand and right hand values.
Or your solution grows in time with O(n^2).
* Find all ancesters of GSELECT * FROM rows WHERE left  [right hand value of G]This is just so wrong, where do I begin.
* Find the nearest common ancestor of D and HSELECT * FROM rows WHERE left  [highest right hand value from D,H] ORDER BY right LIMIT 1Still not working.Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.Are you saying trees are easy or hard?
And for more complex systems, that is what JOINs are for.
SQL is by far the most powerful way and often the fastest way to manipulate data that I know of.
The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation.Finding degrees of affinity in genealogy IS a MATRIX operation (or can be one)!
It can't be solved by a tree alone.
Using a tree philosophy, the fastest solution, would require you to: traverse a person's family relationships, store that result,   traverse the other person's family relationships, then return the relationship with the newest date.
Something that can be done very fast in a properly designed SQL dbs [ 2O(log n) + O(log (O(log n))].
Unfortunately, your design isn't one of those I would call properly designed.
Of, course, I've oversimplified the problem by ignoring the complexities of the Real World.
Such as: adopted children, multiple parents (step parent families), multiple family relationships as a result of cousin marriages, et cetera.
It's really a much more complex problem than your simplistic solution would suggest.
Which is why it is such an interesting problem.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569005</id>
	<title>Re:Pros &amp; Cons of non-relational solutions</title>
	<author>Anonymous</author>
	<datestamp>1246651380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>After re-reading your post, I'm not sure if you know but ebay is transactionless:<br>http://martinfowler.com/bliki/Transactionless.html</p></htmltext>
<tokenext>After re-reading your post , I 'm not sure if you know but ebay is transactionless : http : //martinfowler.com/bliki/Transactionless.html</tokentext>
<sentencetext>After re-reading your post, I'm not sure if you know but ebay is transactionless:http://martinfowler.com/bliki/Transactionless.html</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570167</id>
	<title>Re:IBM's IMS is a Hierarchical Database</title>
	<author>Dark$ide</author>
	<datestamp>1246624620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Now, if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds.</p></div><p>That's not going to happen.</p><p>About 45\% of IMS is still supplied as assembler source to licenced customers. It was first generally available before the IBM dictat that said "all source is confidential" and we'll only supply OCO (object code only) materials to customers.</p><p>
DB2, IBM's hierarchical database was developed by the same people originally as a complete replacement for DL/I. But, DL/I databases are sill alive and well and supporting them is paying my mortgage.</p><p>
It was used as the parts database for the Apollo program, Neil Armstrong wouldn't have made it to "One small step<nobr> <wbr></nobr>..." without IMS</p><p>
IMS is still faster than DB2, but DB2 is easier to use from an application design and application programming point of view. That's why there's a Java/SQL interface to IMS databases.</p></div>
	</htmltext>
<tokenext>Now , if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds.That 's not going to happen.About 45 \ % of IMS is still supplied as assembler source to licenced customers .
It was first generally available before the IBM dictat that said " all source is confidential " and we 'll only supply OCO ( object code only ) materials to customers .
DB2 , IBM 's hierarchical database was developed by the same people originally as a complete replacement for DL/I .
But , DL/I databases are sill alive and well and supporting them is paying my mortgage .
It was used as the parts database for the Apollo program , Neil Armstrong would n't have made it to " One small step ... " without IMS IMS is still faster than DB2 , but DB2 is easier to use from an application design and application programming point of view .
That 's why there 's a Java/SQL interface to IMS databases .</tokentext>
<sentencetext>Now, if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds.That's not going to happen.About 45\% of IMS is still supplied as assembler source to licenced customers.
It was first generally available before the IBM dictat that said "all source is confidential" and we'll only supply OCO (object code only) materials to customers.
DB2, IBM's hierarchical database was developed by the same people originally as a complete replacement for DL/I.
But, DL/I databases are sill alive and well and supporting them is paying my mortgage.
It was used as the parts database for the Apollo program, Neil Armstrong wouldn't have made it to "One small step ..." without IMS
IMS is still faster than DB2, but DB2 is easier to use from an application design and application programming point of view.
That's why there's a Java/SQL interface to IMS databases.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566245</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567445</id>
	<title>The RDBMS responds to the troll</title>
	<author>Anonymous</author>
	<datestamp>1246547100000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>See, I don't think there is ever a good time or place for SQL.</p></div><p>SELECT text FROM mild\_introductory\_statements WHERE id=random();</p><p><div class="quote"><p>Anyone who says so has never had to use it.</p></div><p>SELECT text FROM statements\_indicating\_superior\_experience WHERE id=random();</p><p><div class="quote"><p>I like to compare it with JavaScript.</p></div><p>SELECT text FROM unrelated\_tool WHERE id=random();</p><p><div class="quote"><p>It's a language that is difficult to refactor, maintain, and while it's a standard, the standard is so vague that it's useless.</p></div><p>SELECT text FROM seemingly\_valid\_yet\_unsubstantiated\_objections WHERE id=random();</p><p><div class="quote"><p>Like JavaScript, people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT, and for SQL you have HQL, Linq, etc.</p></div><p>SELECT text FROM wrongheaded\_causal\_analysis WHERE id=same\_one\_as\_two\_queries\_ago();</p><p><div class="quote"><p>Not to say that there is anything wrong with relational databases, we just lack a good tool to interface with them.</p></div><p>SELECT text FROM reasonable\_sounding\_parthian\_shot\_to\_obscure\_trolling WHERE id=random();</p></div>
	</htmltext>
<tokenext>See , I do n't think there is ever a good time or place for SQL.SELECT text FROM mild \ _introductory \ _statements WHERE id = random ( ) ; Anyone who says so has never had to use it.SELECT text FROM statements \ _indicating \ _superior \ _experience WHERE id = random ( ) ; I like to compare it with JavaScript.SELECT text FROM unrelated \ _tool WHERE id = random ( ) ; It 's a language that is difficult to refactor , maintain , and while it 's a standard , the standard is so vague that it 's useless.SELECT text FROM seemingly \ _valid \ _yet \ _unsubstantiated \ _objections WHERE id = random ( ) ; Like JavaScript , people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT , and for SQL you have HQL , Linq , etc.SELECT text FROM wrongheaded \ _causal \ _analysis WHERE id = same \ _one \ _as \ _two \ _queries \ _ago ( ) ; Not to say that there is anything wrong with relational databases , we just lack a good tool to interface with them.SELECT text FROM reasonable \ _sounding \ _parthian \ _shot \ _to \ _obscure \ _trolling WHERE id = random ( ) ;</tokentext>
<sentencetext>See, I don't think there is ever a good time or place for SQL.SELECT text FROM mild\_introductory\_statements WHERE id=random();Anyone who says so has never had to use it.SELECT text FROM statements\_indicating\_superior\_experience WHERE id=random();I like to compare it with JavaScript.SELECT text FROM unrelated\_tool WHERE id=random();It's a language that is difficult to refactor, maintain, and while it's a standard, the standard is so vague that it's useless.SELECT text FROM seemingly\_valid\_yet\_unsubstantiated\_objections WHERE id=random();Like JavaScript, people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT, and for SQL you have HQL, Linq, etc.SELECT text FROM wrongheaded\_causal\_analysis WHERE id=same\_one\_as\_two\_queries\_ago();Not to say that there is anything wrong with relational databases, we just lack a good tool to interface with them.SELECT text FROM reasonable\_sounding\_parthian\_shot\_to\_obscure\_trolling WHERE id=random();
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571815</id>
	<title>Re:Pros &amp; Cons of non-relational solutions</title>
	<author>Anonymous</author>
	<datestamp>1246636680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Fabian Pascal would have a field day with your little dialog there.</p></htmltext>
<tokenext>Fabian Pascal would have a field day with your little dialog there .</tokentext>
<sentencetext>Fabian Pascal would have a field day with your little dialog there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565749</id>
	<title>Re:Tilting at windmills</title>
	<author>CrashandDie</author>
	<datestamp>1246535820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Cheaper and more lightweight than Oracle?<br> <br>

Next thing we're going to hear people wanting a free DBMS...</htmltext>
<tokenext>Cheaper and more lightweight than Oracle ?
Next thing we 're going to hear people wanting a free DBMS.. .</tokentext>
<sentencetext>Cheaper and more lightweight than Oracle?
Next thing we're going to hear people wanting a free DBMS...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567087</id>
	<title>Re:Not mutually exclusive</title>
	<author>convolvatron</author>
	<datestamp>1246544400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>yes, and you can have relational algebra without sql</p></htmltext>
<tokenext>yes , and you can have relational algebra without sql</tokentext>
<sentencetext>yes, and you can have relational algebra without sql</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565357</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569999</id>
	<title>Re:Yeah, so why are they better?</title>
	<author>Anonymous</author>
	<datestamp>1246621980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Like we're using it just because it's <i>the best tool we have</i>, rather than <i>anything else</i>.</p></div><p>Fixed that for ya.</p></div>
	</htmltext>
<tokenext>Like we 're using it just because it 's the best tool we have , rather than anything else.Fixed that for ya .</tokentext>
<sentencetext>Like we're using it just because it's the best tool we have, rather than anything else.Fixed that for ya.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565869</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566997</id>
	<title>Re:Unorthodox user of LDAP?</title>
	<author>hrvatska</author>
	<datestamp>1246543680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Under the covers Tivoli Directory Server, an LDAP server, uses IBM's DB2 as a data store.  It's basically a relational database that's been optimized for use by an LDAP server.</htmltext>
<tokenext>Under the covers Tivoli Directory Server , an LDAP server , uses IBM 's DB2 as a data store .
It 's basically a relational database that 's been optimized for use by an LDAP server .</tokentext>
<sentencetext>Under the covers Tivoli Directory Server, an LDAP server, uses IBM's DB2 as a data store.
It's basically a relational database that's been optimized for use by an LDAP server.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565957</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568619</id>
	<title>Replacing SQL? :)</title>
	<author>youn</author>
	<datestamp>1246559760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yawn... they said that about Cobol... call me when they have actually eliminated Cobol... and in my opinion is a much larger horror than SQL.</p><p>SQL is here to stay... maybe a few enhancements... but it shouldnt change much... too much of criticial stuff is dependent on it... besides, it's surprisingly flexible when it comes to access data</p></htmltext>
<tokenext>Yawn... they said that about Cobol... call me when they have actually eliminated Cobol... and in my opinion is a much larger horror than SQL.SQL is here to stay... maybe a few enhancements... but it shouldnt change much... too much of criticial stuff is dependent on it... besides , it 's surprisingly flexible when it comes to access data</tokentext>
<sentencetext>Yawn... they said that about Cobol... call me when they have actually eliminated Cobol... and in my opinion is a much larger horror than SQL.SQL is here to stay... maybe a few enhancements... but it shouldnt change much... too much of criticial stuff is dependent on it... besides, it's surprisingly flexible when it comes to access data</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565641</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>jyx</author>
	<datestamp>1246535280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>For example, if I want to fetch all customers and all their bids in one query I have to use inner join. And that results in LARGE number of rows (Cartesian product of customers and their bids)</p></div><p>You might want to explain yourself a bit more there, if I want all customers and all their bids I would expect a LARGE number of rows. What magic algorithm is out there that will give you all your data, but at the same time make it less than what it is?</p><p>Or do you want just one row of customer data and then all there orders under that? Good luck getting your admin staff creating reports off that spreadsheet.</p><p>I think what you are interested in reporting tools - they do the things you ask for often in a nice drag and droppy way - but you still need to get the data to those reports and I haven't found anything better for that job than SQL (yet).</p><p>Data is hard work, eventually any solution to querying databases is going to be as complicated as SQL because there is a infinite number of ways people will eventually want to look at it.</p></div>
	</htmltext>
<tokenext>For example , if I want to fetch all customers and all their bids in one query I have to use inner join .
And that results in LARGE number of rows ( Cartesian product of customers and their bids ) You might want to explain yourself a bit more there , if I want all customers and all their bids I would expect a LARGE number of rows .
What magic algorithm is out there that will give you all your data , but at the same time make it less than what it is ? Or do you want just one row of customer data and then all there orders under that ?
Good luck getting your admin staff creating reports off that spreadsheet.I think what you are interested in reporting tools - they do the things you ask for often in a nice drag and droppy way - but you still need to get the data to those reports and I have n't found anything better for that job than SQL ( yet ) .Data is hard work , eventually any solution to querying databases is going to be as complicated as SQL because there is a infinite number of ways people will eventually want to look at it .</tokentext>
<sentencetext>For example, if I want to fetch all customers and all their bids in one query I have to use inner join.
And that results in LARGE number of rows (Cartesian product of customers and their bids)You might want to explain yourself a bit more there, if I want all customers and all their bids I would expect a LARGE number of rows.
What magic algorithm is out there that will give you all your data, but at the same time make it less than what it is?Or do you want just one row of customer data and then all there orders under that?
Good luck getting your admin staff creating reports off that spreadsheet.I think what you are interested in reporting tools - they do the things you ask for often in a nice drag and droppy way - but you still need to get the data to those reports and I haven't found anything better for that job than SQL (yet).Data is hard work, eventually any solution to querying databases is going to be as complicated as SQL because there is a infinite number of ways people will eventually want to look at it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570719</id>
	<title>Re:A time and place for everything</title>
	<author>DiegoBravo</author>
	<datestamp>1246630020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In other words, the "web 2.0 people" wants a database that can be altered in any conceivable way that is convenient to the application programmer as he/she is yet unsure about the needed data model; of course, this can be only work if nothing else is using or will use that database (typically, pet projects.)</p><p>And yes, the ALTER TABLE commands are not very flexible; yet are very understandable for all the IT actors, and reasonably unobtrusive for the production SQL-applications.</p></htmltext>
<tokenext>In other words , the " web 2.0 people " wants a database that can be altered in any conceivable way that is convenient to the application programmer as he/she is yet unsure about the needed data model ; of course , this can be only work if nothing else is using or will use that database ( typically , pet projects .
) And yes , the ALTER TABLE commands are not very flexible ; yet are very understandable for all the IT actors , and reasonably unobtrusive for the production SQL-applications .</tokentext>
<sentencetext>In other words, the "web 2.0 people" wants a database that can be altered in any conceivable way that is convenient to the application programmer as he/she is yet unsure about the needed data model; of course, this can be only work if nothing else is using or will use that database (typically, pet projects.
)And yes, the ALTER TABLE commands are not very flexible; yet are very understandable for all the IT actors, and reasonably unobtrusive for the production SQL-applications.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565583</id>
	<title>Misses the point</title>
	<author>kc8jhs</author>
	<datestamp>1246534980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There are plenty of ways to store data inexpensively in a RDBMS. There are plenty of GPL and low cost RDBMS available.
<br> <br>
The real issue is that the more and more we move into complex data structures and we push the limits of what an ORM can do with those simple, inexpensive RDBMS, the more problems we run into trying to map our objects into rows in tables. <br> <br>
<a href="http://bret.appspot.com/entry/how-friendfeed-uses-mysql" title="appspot.com" rel="nofollow">Here</a> [appspot.com] is one of the more interesting solutions that I've seen to the problem, but it only work over relatively simplistic data where managing indexes by hand is ok, and it's okay for the indexes to be incomplete at any given moment. Ironically, that gives them more availability than trying to force MySQL to do indexes. But it really depends on the data and needs.</htmltext>
<tokenext>There are plenty of ways to store data inexpensively in a RDBMS .
There are plenty of GPL and low cost RDBMS available .
The real issue is that the more and more we move into complex data structures and we push the limits of what an ORM can do with those simple , inexpensive RDBMS , the more problems we run into trying to map our objects into rows in tables .
Here [ appspot.com ] is one of the more interesting solutions that I 've seen to the problem , but it only work over relatively simplistic data where managing indexes by hand is ok , and it 's okay for the indexes to be incomplete at any given moment .
Ironically , that gives them more availability than trying to force MySQL to do indexes .
But it really depends on the data and needs .</tokentext>
<sentencetext>There are plenty of ways to store data inexpensively in a RDBMS.
There are plenty of GPL and low cost RDBMS available.
The real issue is that the more and more we move into complex data structures and we push the limits of what an ORM can do with those simple, inexpensive RDBMS, the more problems we run into trying to map our objects into rows in tables.
Here [appspot.com] is one of the more interesting solutions that I've seen to the problem, but it only work over relatively simplistic data where managing indexes by hand is ok, and it's okay for the indexes to be incomplete at any given moment.
Ironically, that gives them more availability than trying to force MySQL to do indexes.
But it really depends on the data and needs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574837</id>
	<title>Re:Quit Whining</title>
	<author>CyberLife</author>
	<datestamp>1246613640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think the point many are missing is that software system architecture is not all about the data. It may be a large part of things, but it's by no means the only concern. Walking into a project with the preconception that one requires what a relational system has to offer is rather naive.</p></htmltext>
<tokenext>I think the point many are missing is that software system architecture is not all about the data .
It may be a large part of things , but it 's by no means the only concern .
Walking into a project with the preconception that one requires what a relational system has to offer is rather naive .</tokentext>
<sentencetext>I think the point many are missing is that software system architecture is not all about the data.
It may be a large part of things, but it's by no means the only concern.
Walking into a project with the preconception that one requires what a relational system has to offer is rather naive.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569807</id>
	<title>Re:Quit Whining</title>
	<author>Jarlsberg</author>
	<datestamp>1246619100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well, that's why I am so in favor of SQLite. While it does use SQL syntax, in reality you're simply rummaging through a flat file with superspeed. I use SQLite on all my simpler web projects that doesn't need the advanced functions that you get with a fully fledged relational database.</htmltext>
<tokenext>Well , that 's why I am so in favor of SQLite .
While it does use SQL syntax , in reality you 're simply rummaging through a flat file with superspeed .
I use SQLite on all my simpler web projects that does n't need the advanced functions that you get with a fully fledged relational database .</tokentext>
<sentencetext>Well, that's why I am so in favor of SQLite.
While it does use SQL syntax, in reality you're simply rummaging through a flat file with superspeed.
I use SQLite on all my simpler web projects that doesn't need the advanced functions that you get with a fully fledged relational database.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565357</id>
	<title>Not mutually exclusive</title>
	<author>JobyOne</author>
	<datestamp>1246533660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>It's pretty easy to say "yes" to alternatives without saying "no" to SQL.<br> <br>

Just because a crowbar can pull out a stubborn nail better doesn't mean they should replace all the hammers.  Then what would we put nails in with?  Different tools for different jobs.</htmltext>
<tokenext>It 's pretty easy to say " yes " to alternatives without saying " no " to SQL .
Just because a crowbar can pull out a stubborn nail better does n't mean they should replace all the hammers .
Then what would we put nails in with ?
Different tools for different jobs .</tokentext>
<sentencetext>It's pretty easy to say "yes" to alternatives without saying "no" to SQL.
Just because a crowbar can pull out a stubborn nail better doesn't mean they should replace all the hammers.
Then what would we put nails in with?
Different tools for different jobs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565539</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>Anonymous</author>
	<datestamp>1246534680000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>select * from customers c, bids b where c.customer\_id=b.fk\_customer\_id order by c.customer\_id, b.bid\_date</p><p>Seems pretty simple. What's wrong with an inner join? Your getting exactly the number of rows that you need to answer your question, no more no less.</p><p>A cartesian product would be more like: select * from customers c, bids b. But that's not what you want.</p><p>As for hierarchical structures, Oracle db has ways to do this, although I admit the syntax isn't that straight forward: http://download.oracle.com/docs/cd/B19306\_01/server.102/b14200/queries003.htm</p></htmltext>
<tokenext>select * from customers c , bids b where c.customer \ _id = b.fk \ _customer \ _id order by c.customer \ _id , b.bid \ _dateSeems pretty simple .
What 's wrong with an inner join ?
Your getting exactly the number of rows that you need to answer your question , no more no less.A cartesian product would be more like : select * from customers c , bids b. But that 's not what you want.As for hierarchical structures , Oracle db has ways to do this , although I admit the syntax is n't that straight forward : http : //download.oracle.com/docs/cd/B19306 \ _01/server.102/b14200/queries003.htm</tokentext>
<sentencetext>select * from customers c, bids b where c.customer\_id=b.fk\_customer\_id order by c.customer\_id, b.bid\_dateSeems pretty simple.
What's wrong with an inner join?
Your getting exactly the number of rows that you need to answer your question, no more no less.A cartesian product would be more like: select * from customers c, bids b. But that's not what you want.As for hierarchical structures, Oracle db has ways to do this, although I admit the syntax isn't that straight forward: http://download.oracle.com/docs/cd/B19306\_01/server.102/b14200/queries003.htm</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570207</id>
	<title>Re:Quit Whining</title>
	<author>ShieldW0lf</author>
	<datestamp>1246625220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How these databases work:</p><p>1) Ask X nodes if they have information that relates to subject Y.<br>2) Wait Z period of time for an answer<br>3) Take the answers you got from what nodes answered in Z time, form a conclusion</p><p>The way this works in plain English is, poll a million people on a subject, give them a time limit to answer, ignore those who don't answer in the time limit, form their collective opinions into a result, call it a day.  If 10,000 of those people on your list are dead and 50,000 are in jail and 30,000 didn't get the message and none of those people answered, you don't know, you don't care.</p><p>If you can re-think your application so it works within this paradigm, this technology will work.  If you can't, it won't.</p><p>For things like search engines or suggesting a vaguely related item that you might also want to purchase, this is fine.  Anywhere you need to spit out SOME kind of answer, without consistent accuracy being essential, this is a good way to do it.</p><p>It's not going to become a replacement for RDBMS' as a tool.  Pitching it that way is stupid.  It is a supplemental tool for an entirely different category of problems.</p></htmltext>
<tokenext>How these databases work : 1 ) Ask X nodes if they have information that relates to subject Y.2 ) Wait Z period of time for an answer3 ) Take the answers you got from what nodes answered in Z time , form a conclusionThe way this works in plain English is , poll a million people on a subject , give them a time limit to answer , ignore those who do n't answer in the time limit , form their collective opinions into a result , call it a day .
If 10,000 of those people on your list are dead and 50,000 are in jail and 30,000 did n't get the message and none of those people answered , you do n't know , you do n't care.If you can re-think your application so it works within this paradigm , this technology will work .
If you ca n't , it wo n't.For things like search engines or suggesting a vaguely related item that you might also want to purchase , this is fine .
Anywhere you need to spit out SOME kind of answer , without consistent accuracy being essential , this is a good way to do it.It 's not going to become a replacement for RDBMS ' as a tool .
Pitching it that way is stupid .
It is a supplemental tool for an entirely different category of problems .</tokentext>
<sentencetext>How these databases work:1) Ask X nodes if they have information that relates to subject Y.2) Wait Z period of time for an answer3) Take the answers you got from what nodes answered in Z time, form a conclusionThe way this works in plain English is, poll a million people on a subject, give them a time limit to answer, ignore those who don't answer in the time limit, form their collective opinions into a result, call it a day.
If 10,000 of those people on your list are dead and 50,000 are in jail and 30,000 didn't get the message and none of those people answered, you don't know, you don't care.If you can re-think your application so it works within this paradigm, this technology will work.
If you can't, it won't.For things like search engines or suggesting a vaguely related item that you might also want to purchase, this is fine.
Anywhere you need to spit out SOME kind of answer, without consistent accuracy being essential, this is a good way to do it.It's not going to become a replacement for RDBMS' as a tool.
Pitching it that way is stupid.
It is a supplemental tool for an entirely different category of problems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566589</id>
	<title>Not going to happen</title>
	<author>russotto</author>
	<datestamp>1246540680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>SELECT * FROM DB WHERE DBCLASS='REAL' QUERY\_LANGUAGE NOT LIKE '\%SQL\%'<br>0 Rows Returned</p><p>(Stupid slashdot yelling filter.  I hate queries in lowercase. )</p></htmltext>
<tokenext>SELECT * FROM DB WHERE DBCLASS = 'REAL ' QUERY \ _LANGUAGE NOT LIKE ' \ % SQL \ % '0 Rows Returned ( Stupid slashdot yelling filter .
I hate queries in lowercase .
)</tokentext>
<sentencetext>SELECT * FROM DB WHERE DBCLASS='REAL' QUERY\_LANGUAGE NOT LIKE '\%SQL\%'0 Rows Returned(Stupid slashdot yelling filter.
I hate queries in lowercase.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578037</id>
	<title>Re:A time and place for everything</title>
	<author>BitZtream</author>
	<datestamp>1246646640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You use use LDAP for genetic data then?   Seems like it would fit perfectly.</p></htmltext>
<tokenext>You use use LDAP for genetic data then ?
Seems like it would fit perfectly .</tokentext>
<sentencetext>You use use LDAP for genetic data then?
Seems like it would fit perfectly.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151</id>
	<title>Tilting at windmills</title>
	<author>Anonymous</author>
	<datestamp>1246532580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Seems to be a silly thing to be against. Relational databases and the stuctured query language may not be perfect, but I bet these people could die in their 90's and people will still be using relational dbs and sql.</p><p>If you want to tout open or cheap dbs and more lightweight types of storage/db servers, then they might have some points, but being against sql is just plain dumb.</p></htmltext>
<tokenext>Seems to be a silly thing to be against .
Relational databases and the stuctured query language may not be perfect , but I bet these people could die in their 90 's and people will still be using relational dbs and sql.If you want to tout open or cheap dbs and more lightweight types of storage/db servers , then they might have some points , but being against sql is just plain dumb .</tokentext>
<sentencetext>Seems to be a silly thing to be against.
Relational databases and the stuctured query language may not be perfect, but I bet these people could die in their 90's and people will still be using relational dbs and sql.If you want to tout open or cheap dbs and more lightweight types of storage/db servers, then they might have some points, but being against sql is just plain dumb.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367</id>
	<title>Re:A time and place for everything</title>
	<author>Bromskloss</author>
	<datestamp>1246533660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>

<p>It would be interesting to hear why this is.</p></htmltext>
<tokenext>It would be interesting to hear why this is .</tokentext>
<sentencetext>

It would be interesting to hear why this is.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570725</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246630020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Huh? Tree structures are <i>best</i> handled by relational databases, as it is far faster then recursion.</p></div><p>Far faster than recursion?  That's a tautology that just isn't true.  In many cases, properly tail-recursive language can handle recursion much faster than the alternative. (Scheme, Lisp)</p><p>But in most SQL systems, tree tables are HORRIBLE to deal with.  If you're dealing with a tree table in MySQL, and have a table with 10,000 rows and you want to traverse the tree, you have to make another SQL call for each iteration.  Having O(n) sql calls for a tree will destroy your efficiency.  It forces you to make LOTS of small SQL calls and that's terrible.</p><p>The only exception that I know of is CONNECT BY PRIOR in oracle which can do it in one single query.  This will speed up your queries a lot</p></div>
	</htmltext>
<tokenext>Huh ?
Tree structures are best handled by relational databases , as it is far faster then recursion.Far faster than recursion ?
That 's a tautology that just is n't true .
In many cases , properly tail-recursive language can handle recursion much faster than the alternative .
( Scheme , Lisp ) But in most SQL systems , tree tables are HORRIBLE to deal with .
If you 're dealing with a tree table in MySQL , and have a table with 10,000 rows and you want to traverse the tree , you have to make another SQL call for each iteration .
Having O ( n ) sql calls for a tree will destroy your efficiency .
It forces you to make LOTS of small SQL calls and that 's terrible.The only exception that I know of is CONNECT BY PRIOR in oracle which can do it in one single query .
This will speed up your queries a lot</tokentext>
<sentencetext>Huh?
Tree structures are best handled by relational databases, as it is far faster then recursion.Far faster than recursion?
That's a tautology that just isn't true.
In many cases, properly tail-recursive language can handle recursion much faster than the alternative.
(Scheme, Lisp)But in most SQL systems, tree tables are HORRIBLE to deal with.
If you're dealing with a tree table in MySQL, and have a table with 10,000 rows and you want to traverse the tree, you have to make another SQL call for each iteration.
Having O(n) sql calls for a tree will destroy your efficiency.
It forces you to make LOTS of small SQL calls and that's terrible.The only exception that I know of is CONNECT BY PRIOR in oracle which can do it in one single query.
This will speed up your queries a lot
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572609</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246641720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2),</p></div><p>And what happens when you need to insert an object (row) into the tree? Or 1,000 objects? Do you now have to adjust all of the right hand numbers? All 5 million of them?</p></div>
	</htmltext>
<tokenext>in addition , a left hand and right hand number , the root node having a left-hand value of 1 and a right hand value of ( number rows * 2 ) ,And what happens when you need to insert an object ( row ) into the tree ?
Or 1,000 objects ?
Do you now have to adjust all of the right hand numbers ?
All 5 million of them ?</tokentext>
<sentencetext>in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2),And what happens when you need to insert an object (row) into the tree?
Or 1,000 objects?
Do you now have to adjust all of the right hand numbers?
All 5 million of them?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569301</id>
	<title>Ditch SQL, not Relational DBs!</title>
	<author>Lord Bitman</author>
	<datestamp>1246612320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>SQL syntax sucks, is inconsistent, and just non-standard enough at its corners that it's completely annoying to write anything for more than one DB. Also lacks various features which logically \_should\_ be there, because of the relational back-end. SQL is a toy, and though I'm the guy everyone in the office turns to if they want to write a query that does more than SELECT * FROM sometable, that doesn't mean I have to like it.</p><p>But that's not the fault of relational databases. The relational logic makes sense, and we'll be seeing it referenced in countless "new ideas" that come along for years, just as ideas which Lisp already had in 1970 will be touted a new features on for the next millennium (you hear? PHP can do Lambda functions as of yesterday!)</p><p>SQL sucks, but SQL is NOT what makes something relational.</p></htmltext>
<tokenext>SQL syntax sucks , is inconsistent , and just non-standard enough at its corners that it 's completely annoying to write anything for more than one DB .
Also lacks various features which logically \ _should \ _ be there , because of the relational back-end .
SQL is a toy , and though I 'm the guy everyone in the office turns to if they want to write a query that does more than SELECT * FROM sometable , that does n't mean I have to like it.But that 's not the fault of relational databases .
The relational logic makes sense , and we 'll be seeing it referenced in countless " new ideas " that come along for years , just as ideas which Lisp already had in 1970 will be touted a new features on for the next millennium ( you hear ?
PHP can do Lambda functions as of yesterday !
) SQL sucks , but SQL is NOT what makes something relational .</tokentext>
<sentencetext>SQL syntax sucks, is inconsistent, and just non-standard enough at its corners that it's completely annoying to write anything for more than one DB.
Also lacks various features which logically \_should\_ be there, because of the relational back-end.
SQL is a toy, and though I'm the guy everyone in the office turns to if they want to write a query that does more than SELECT * FROM sometable, that doesn't mean I have to like it.But that's not the fault of relational databases.
The relational logic makes sense, and we'll be seeing it referenced in countless "new ideas" that come along for years, just as ideas which Lisp already had in 1970 will be touted a new features on for the next millennium (you hear?
PHP can do Lambda functions as of yesterday!
)SQL sucks, but SQL is NOT what makes something relational.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</id>
	<title>Re:A time and place for everything</title>
	<author>Carewolf</author>
	<datestamp>1246534560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Design an efficient table relating a tree structure. Then design queries to answer questions such as:<br>* Find the nodes in the subtree under B.<br>* Find all ancesters of G<br>* Find the nearest common ancestor of D and H</p><p>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.</p></htmltext>
<tokenext>Design an efficient table relating a tree structure .
Then design queries to answer questions such as : * Find the nodes in the subtree under B .
* Find all ancesters of G * Find the nearest common ancestor of D and HTrees is a wellknown problem of SQL , but the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional ones .</tokentext>
<sentencetext>Design an efficient table relating a tree structure.
Then design queries to answer questions such as:* Find the nodes in the subtree under B.
* Find all ancesters of G* Find the nearest common ancestor of D and HTrees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105</id>
	<title>Quit Whining</title>
	<author>Anonymous</author>
	<datestamp>1246532220000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>Just use flat text files --- no need for expensive db's<nobr> <wbr></nobr>.... think of the freedom!</htmltext>
<tokenext>Just use flat text files --- no need for expensive db 's .... think of the freedom !</tokentext>
<sentencetext>Just use flat text files --- no need for expensive db's .... think of the freedom!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567827</id>
	<title>Re:Quit Whining</title>
	<author>Anonymous</author>
	<datestamp>1246551120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Hey, an Excel spreadsheet is a great substitute for a multi gig BD too.</p></htmltext>
<tokenext>Hey , an Excel spreadsheet is a great substitute for a multi gig BD too .</tokentext>
<sentencetext>Hey, an Excel spreadsheet is a great substitute for a multi gig BD too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565775</id>
	<title>Re:Quit Whining</title>
	<author>rubycodez</author>
	<datestamp>1246535940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I"ve lost data in two filesystems thanks to the Slasher's shoddy work.</p></htmltext>
<tokenext>I " ve lost data in two filesystems thanks to the Slasher 's shoddy work .</tokentext>
<sentencetext>I"ve lost data in two filesystems thanks to the Slasher's shoddy work.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567311</id>
	<title>How hard is it to understand?</title>
	<author>dread</author>
	<datestamp>1246545960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Use the appropriate tool. Always. There are tons.</p><p>Don't use a relational database to try to represent hierarchical data. Don't try to use LDAP to do analytics. Think of the performance implications before you have more than two users accessing your system. Data storage is a very different animal, you are often (though not always) I/O bound. This is very different from being limited by the amount of instructions you can deal with per unit of time. Don't think otherwise because it will bite you in the ass.</p><p>And still I see people making the same stupid mistakes over and over. But it's pretty simple really:</p><p>A solution designed to be generic will ALWAYS be slower than a solution that is customized. This shouldn't be surprising. If you have serious performance requirements (ESPECIALLY if they are coupled with huge amounts of data) then a custom solution is definitely something you should look into. At some point you will run into a brick wall and find out that there is stuff you can't do with the solution you have in place. This is natural. Custom solutions to hard problems always lead to restrictions in terms of future features. Always. You will NEVER be able to anticipate all features that you would like to have. (Yes, this is true for Google as well. No they don't have any special kind of magic dust that they sprinkle on their things there, they do the best they can and then they get bitten in the ass too, just like everybody else.)</p></htmltext>
<tokenext>Use the appropriate tool .
Always. There are tons.Do n't use a relational database to try to represent hierarchical data .
Do n't try to use LDAP to do analytics .
Think of the performance implications before you have more than two users accessing your system .
Data storage is a very different animal , you are often ( though not always ) I/O bound .
This is very different from being limited by the amount of instructions you can deal with per unit of time .
Do n't think otherwise because it will bite you in the ass.And still I see people making the same stupid mistakes over and over .
But it 's pretty simple really : A solution designed to be generic will ALWAYS be slower than a solution that is customized .
This should n't be surprising .
If you have serious performance requirements ( ESPECIALLY if they are coupled with huge amounts of data ) then a custom solution is definitely something you should look into .
At some point you will run into a brick wall and find out that there is stuff you ca n't do with the solution you have in place .
This is natural .
Custom solutions to hard problems always lead to restrictions in terms of future features .
Always. You will NEVER be able to anticipate all features that you would like to have .
( Yes , this is true for Google as well .
No they do n't have any special kind of magic dust that they sprinkle on their things there , they do the best they can and then they get bitten in the ass too , just like everybody else .
)</tokentext>
<sentencetext>Use the appropriate tool.
Always. There are tons.Don't use a relational database to try to represent hierarchical data.
Don't try to use LDAP to do analytics.
Think of the performance implications before you have more than two users accessing your system.
Data storage is a very different animal, you are often (though not always) I/O bound.
This is very different from being limited by the amount of instructions you can deal with per unit of time.
Don't think otherwise because it will bite you in the ass.And still I see people making the same stupid mistakes over and over.
But it's pretty simple really:A solution designed to be generic will ALWAYS be slower than a solution that is customized.
This shouldn't be surprising.
If you have serious performance requirements (ESPECIALLY if they are coupled with huge amounts of data) then a custom solution is definitely something you should look into.
At some point you will run into a brick wall and find out that there is stuff you can't do with the solution you have in place.
This is natural.
Custom solutions to hard problems always lead to restrictions in terms of future features.
Always. You will NEVER be able to anticipate all features that you would like to have.
(Yes, this is true for Google as well.
No they don't have any special kind of magic dust that they sprinkle on their things there, they do the best they can and then they get bitten in the ass too, just like everybody else.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567801</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246550880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's not hard at all and something I have implemented many times.  Some peoples ideas of difficulty are a little strange. If there wasn't some degree of difficulty with programming, they'd call it sitting on the beach drinking martinis.</p></htmltext>
<tokenext>That 's not hard at all and something I have implemented many times .
Some peoples ideas of difficulty are a little strange .
If there was n't some degree of difficulty with programming , they 'd call it sitting on the beach drinking martinis .</tokentext>
<sentencetext>That's not hard at all and something I have implemented many times.
Some peoples ideas of difficulty are a little strange.
If there wasn't some degree of difficulty with programming, they'd call it sitting on the beach drinking martinis.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246535160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>See, I don't think there is ever a good time or place for SQL.  Anyone who says so has never had to use it.  I like to compare it with JavaScript.  It's a language that is difficult to refactor, maintain, and while it's a standard, the standard is so vague that it's useless.  Like JavaScript, people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT, and for SQL you have HQL, Linq, etc.</p><p>Not to say that there is anything wrong with relational databases, we just lack a good tool to interface with them.</p></htmltext>
<tokenext>See , I do n't think there is ever a good time or place for SQL .
Anyone who says so has never had to use it .
I like to compare it with JavaScript .
It 's a language that is difficult to refactor , maintain , and while it 's a standard , the standard is so vague that it 's useless .
Like JavaScript , people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT , and for SQL you have HQL , Linq , etc.Not to say that there is anything wrong with relational databases , we just lack a good tool to interface with them .</tokentext>
<sentencetext>See, I don't think there is ever a good time or place for SQL.
Anyone who says so has never had to use it.
I like to compare it with JavaScript.
It's a language that is difficult to refactor, maintain, and while it's a standard, the standard is so vague that it's useless.
Like JavaScript, people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT, and for SQL you have HQL, Linq, etc.Not to say that there is anything wrong with relational databases, we just lack a good tool to interface with them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565531</id>
	<title>Re:A time and place for everything</title>
	<author>MichaelSmith</author>
	<datestamp>1246534620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>It would be interesting to hear why this is.</p></div><p>My guess would be that because SQL is a Structured Query Language it is best used for handling structured data. If you have serial, unstructured data you have to invent your own format for it to use inside the database, and then the query language isn't helping you.</p></div>
	</htmltext>
<tokenext>It would be interesting to hear why this is.My guess would be that because SQL is a Structured Query Language it is best used for handling structured data .
If you have serial , unstructured data you have to invent your own format for it to use inside the database , and then the query language is n't helping you .</tokentext>
<sentencetext>It would be interesting to hear why this is.My guess would be that because SQL is a Structured Query Language it is best used for handling structured data.
If you have serial, unstructured data you have to invent your own format for it to use inside the database, and then the query language isn't helping you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570317</id>
	<title>Re:A time and place for everything</title>
	<author>dargaud</author>
	<datestamp>1246626780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>* Find the nodes in the subtree under B.
* Find all ancesters of G
* Find the nearest common ancestor of D and H</p></div><p>I am a very bad SQL programmer (but an experienced C coder), so I'd be interested to know how to do this in SQL... I've never been able to make much sense out of this so called 'language'.</p></div>
	</htmltext>
<tokenext>* Find the nodes in the subtree under B .
* Find all ancesters of G * Find the nearest common ancestor of D and HI am a very bad SQL programmer ( but an experienced C coder ) , so I 'd be interested to know how to do this in SQL... I 've never been able to make much sense out of this so called 'language' .</tokentext>
<sentencetext>* Find the nodes in the subtree under B.
* Find all ancesters of G
* Find the nearest common ancestor of D and HI am a very bad SQL programmer (but an experienced C coder), so I'd be interested to know how to do this in SQL... I've never been able to make much sense out of this so called 'language'.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565555</id>
	<title>XML / XPATH / XQUERY / XSLT / Xhausted</title>
	<author>Anonymous</author>
	<datestamp>1246534740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>SQL can suck.  The alternatives the PHB might choose aren't necessarily better.  Be careful what you wish for.</p></htmltext>
<tokenext>SQL can suck .
The alternatives the PHB might choose are n't necessarily better .
Be careful what you wish for .</tokentext>
<sentencetext>SQL can suck.
The alternatives the PHB might choose aren't necessarily better.
Be careful what you wish for.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28573983</id>
	<title>Re:The problem is performance not SQL</title>
	<author>celtic\_hackr</author>
	<datestamp>1246650360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You can also assume magical fairy dust and free energy, but that doesn't make it so.  You can <i>ask</i> if there are better ways, but you can't <i>assume</i> it, and in the end you will find <b>there is no magic</b>.</p><p>Clusters and replication are NOT NEW.  Not even remotely new.  There is, in fact, nothing new architecturally at <i>all</i> that would indicate some new capability that hasn't already been repeatedly analyzed and tried.</p></div><p>
Wheel bearings were invented by the Danes around 400 AD (or BC), Ball bearings were invented around 1770.<br>
Just because, something is repeatedly analyzed and tried, doesn't mean that there isn't a better way. Using your logic we might as well say, there is nothing new or undiscovered under the Sun, Moon, and Stars (tm). Just because something is good and works doesn't mean we shouldn't constantly be looking for better ways. I'm sure the first time a person saw sulfur on the stick used to make fire it would seem like magic to someone still using a flint to make fire. Who is to say there isn't some drastically better algorithm just over the horizon? I personally welcome these innovative, skeptical people looking for something better.</p></div>
	</htmltext>
<tokenext>You can also assume magical fairy dust and free energy , but that does n't make it so .
You can ask if there are better ways , but you ca n't assume it , and in the end you will find there is no magic.Clusters and replication are NOT NEW .
Not even remotely new .
There is , in fact , nothing new architecturally at all that would indicate some new capability that has n't already been repeatedly analyzed and tried .
Wheel bearings were invented by the Danes around 400 AD ( or BC ) , Ball bearings were invented around 1770 .
Just because , something is repeatedly analyzed and tried , does n't mean that there is n't a better way .
Using your logic we might as well say , there is nothing new or undiscovered under the Sun , Moon , and Stars ( tm ) .
Just because something is good and works does n't mean we should n't constantly be looking for better ways .
I 'm sure the first time a person saw sulfur on the stick used to make fire it would seem like magic to someone still using a flint to make fire .
Who is to say there is n't some drastically better algorithm just over the horizon ?
I personally welcome these innovative , skeptical people looking for something better .</tokentext>
<sentencetext>You can also assume magical fairy dust and free energy, but that doesn't make it so.
You can ask if there are better ways, but you can't assume it, and in the end you will find there is no magic.Clusters and replication are NOT NEW.
Not even remotely new.
There is, in fact, nothing new architecturally at all that would indicate some new capability that hasn't already been repeatedly analyzed and tried.
Wheel bearings were invented by the Danes around 400 AD (or BC), Ball bearings were invented around 1770.
Just because, something is repeatedly analyzed and tried, doesn't mean that there isn't a better way.
Using your logic we might as well say, there is nothing new or undiscovered under the Sun, Moon, and Stars (tm).
Just because something is good and works doesn't mean we shouldn't constantly be looking for better ways.
I'm sure the first time a person saw sulfur on the stick used to make fire it would seem like magic to someone still using a flint to make fire.
Who is to say there isn't some drastically better algorithm just over the horizon?
I personally welcome these innovative, skeptical people looking for something better.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565955</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569505</id>
	<title>Cloudscape/Derby</title>
	<author>Kupfernigk</author>
	<datestamp>1246615440000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Yes, and Java persistence systems (Hibernate) suck dreadfully; they are a solution for which there is no problem. By the time you've learned the mess that is Hibernate, you can have learned SQL and the Java Collections well enough to be able to knock up any persistence model you need in no time flat.<p>Derby 10.5, meanwhile, still has a tiny footprint, and can do most if not all of the SQL you will ever want for a typical Java application, along with features like the ability to do live backups, live table compaction from within the application while running, and now at last the ability to do cursoring in SELECT statements. Installation and configuration are simple.</p><p>I actually think that the actual problem is that we old C programmers actually learned programming and data structures, and as a result know a lot about the kind of problems for which SQL is well suited, while a lot of modern programmers learn a lot of theory about OO, but don't actually learn to program. Therefore, they have to try to reinvent wheels that were in fact designed in the 70s, and have no idea of what tools are available and how they map onto typical real-world application level problems.</p></htmltext>
<tokenext>Yes , and Java persistence systems ( Hibernate ) suck dreadfully ; they are a solution for which there is no problem .
By the time you 've learned the mess that is Hibernate , you can have learned SQL and the Java Collections well enough to be able to knock up any persistence model you need in no time flat.Derby 10.5 , meanwhile , still has a tiny footprint , and can do most if not all of the SQL you will ever want for a typical Java application , along with features like the ability to do live backups , live table compaction from within the application while running , and now at last the ability to do cursoring in SELECT statements .
Installation and configuration are simple.I actually think that the actual problem is that we old C programmers actually learned programming and data structures , and as a result know a lot about the kind of problems for which SQL is well suited , while a lot of modern programmers learn a lot of theory about OO , but do n't actually learn to program .
Therefore , they have to try to reinvent wheels that were in fact designed in the 70s , and have no idea of what tools are available and how they map onto typical real-world application level problems .</tokentext>
<sentencetext>Yes, and Java persistence systems (Hibernate) suck dreadfully; they are a solution for which there is no problem.
By the time you've learned the mess that is Hibernate, you can have learned SQL and the Java Collections well enough to be able to knock up any persistence model you need in no time flat.Derby 10.5, meanwhile, still has a tiny footprint, and can do most if not all of the SQL you will ever want for a typical Java application, along with features like the ability to do live backups, live table compaction from within the application while running, and now at last the ability to do cursoring in SELECT statements.
Installation and configuration are simple.I actually think that the actual problem is that we old C programmers actually learned programming and data structures, and as a result know a lot about the kind of problems for which SQL is well suited, while a lot of modern programmers learn a lot of theory about OO, but don't actually learn to program.
Therefore, they have to try to reinvent wheels that were in fact designed in the 70s, and have no idea of what tools are available and how they map onto typical real-world application level problems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568207</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246554360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can actually do slightly better than this using single numbers (rather than ranges) via <a href="http://www.uwm.edu/Dept/Math/Farey.html" title="uwm.edu" rel="nofollow">Farey trees</a> [uwm.edu]. That gives optimal memory usage for a given tree size, and doesn't require changing extant nodes to insert a new node.</p></htmltext>
<tokenext>You can actually do slightly better than this using single numbers ( rather than ranges ) via Farey trees [ uwm.edu ] .
That gives optimal memory usage for a given tree size , and does n't require changing extant nodes to insert a new node .</tokentext>
<sentencetext>You can actually do slightly better than this using single numbers (rather than ranges) via Farey trees [uwm.edu].
That gives optimal memory usage for a given tree size, and doesn't require changing extant nodes to insert a new node.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569653</id>
	<title>Re:A time and place for everything</title>
	<author>Burnhard</author>
	<datestamp>1246616940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.</p></div>
</blockquote><p>

Trees aren't so difficult to manage in SQL.  There are various strategies you could use, the simplest of which is to store a path string with each node (of the form 0001\0002\0041, etc.) there are more complex solutions of course).  MSSQL now has hierarchyid enabling native tree structure handling too.  I'm not saying that they are conceptually easy to implement or particularly efficient if that is your primary requirement, but they can be done without too much pain and suffering.</p></div>
	</htmltext>
<tokenext>Trees is a wellknown problem of SQL , but the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional ones .
Trees are n't so difficult to manage in SQL .
There are various strategies you could use , the simplest of which is to store a path string with each node ( of the form 0001 \ 0002 \ 0041 , etc .
) there are more complex solutions of course ) .
MSSQL now has hierarchyid enabling native tree structure handling too .
I 'm not saying that they are conceptually easy to implement or particularly efficient if that is your primary requirement , but they can be done without too much pain and suffering .</tokentext>
<sentencetext>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.
Trees aren't so difficult to manage in SQL.
There are various strategies you could use, the simplest of which is to store a path string with each node (of the form 0001\0002\0041, etc.
) there are more complex solutions of course).
MSSQL now has hierarchyid enabling native tree structure handling too.
I'm not saying that they are conceptually easy to implement or particularly efficient if that is your primary requirement, but they can be done without too much pain and suffering.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371</id>
	<title>Yeah, so why are they better?</title>
	<author>Anonymous</author>
	<datestamp>1246533720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>If I was to read the article, I bet somewhere someone would be wittering on about Key Value Datastores.</p><p>The brainchild of a generation brought up on high level collections, they learn one (in this case Map) and apply it to everything.</p><p>Sadly SQL, and RDBMS, works for most people. It maps object data well (oh whaaaa, i have to do foreign keys - GROW SOME FUCKING BALLS YOU LAZY GRADUATE!) and it is well understood. And with abstractions like LINQ to query them, even the lazy dumb Windows<nobr> <wbr></nobr>.NET programmer doesn't have to strain their brain to learn SQL.</p><p>And when you have terabytes of specific unique data, you clearly should go away to work out how best to store it. Even a RDBMS/SQL solution is too generic for all problems.</p></htmltext>
<tokenext>If I was to read the article , I bet somewhere someone would be wittering on about Key Value Datastores.The brainchild of a generation brought up on high level collections , they learn one ( in this case Map ) and apply it to everything.Sadly SQL , and RDBMS , works for most people .
It maps object data well ( oh whaaaa , i have to do foreign keys - GROW SOME FUCKING BALLS YOU LAZY GRADUATE !
) and it is well understood .
And with abstractions like LINQ to query them , even the lazy dumb Windows .NET programmer does n't have to strain their brain to learn SQL.And when you have terabytes of specific unique data , you clearly should go away to work out how best to store it .
Even a RDBMS/SQL solution is too generic for all problems .</tokentext>
<sentencetext>If I was to read the article, I bet somewhere someone would be wittering on about Key Value Datastores.The brainchild of a generation brought up on high level collections, they learn one (in this case Map) and apply it to everything.Sadly SQL, and RDBMS, works for most people.
It maps object data well (oh whaaaa, i have to do foreign keys - GROW SOME FUCKING BALLS YOU LAZY GRADUATE!
) and it is well understood.
And with abstractions like LINQ to query them, even the lazy dumb Windows .NET programmer doesn't have to strain their brain to learn SQL.And when you have terabytes of specific unique data, you clearly should go away to work out how best to store it.
Even a RDBMS/SQL solution is too generic for all problems.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568139</id>
	<title>Re:A time and place for everything</title>
	<author>pvera</author>
	<datestamp>1246553760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>As a web programmer, I wanted to take offense at your statement, but something that happened to me only a few weeks ago is making me have a hell of a lot less faith about the available pool of web programmers out there:</p><p>During a round of interviews, we sent out a take-home quiz. We mostly wanted to know if the candidates either knew the actual answers, or could at least google it. One of the questions involved simple aggregates in SQL. Given a table with a unique id and a date of birth, I wanted a query that would produce a list of the months of the year, and how many unique records had a DOB that fell on that month. It's a one-liner.</p><p>One of my candidates wrote TWELVE counting queries, each one counting DOBs between the (hardcoded) start and end of each month, then she used UNION to make it send out the 12 one-row queries as one 12-row query.</p><p>Both of us evaluating the results screamed when we read her answer, and we did not pursue her further. I used to complain that programmers simply didn't give a shit about learning beyond the querying aspects of the RDBMS, which kept us at the mercy of overpaid DBAs. Now? Now we are starting to see that programmers don't even give a shit about learning how to query.</p></htmltext>
<tokenext>As a web programmer , I wanted to take offense at your statement , but something that happened to me only a few weeks ago is making me have a hell of a lot less faith about the available pool of web programmers out there : During a round of interviews , we sent out a take-home quiz .
We mostly wanted to know if the candidates either knew the actual answers , or could at least google it .
One of the questions involved simple aggregates in SQL .
Given a table with a unique id and a date of birth , I wanted a query that would produce a list of the months of the year , and how many unique records had a DOB that fell on that month .
It 's a one-liner.One of my candidates wrote TWELVE counting queries , each one counting DOBs between the ( hardcoded ) start and end of each month , then she used UNION to make it send out the 12 one-row queries as one 12-row query.Both of us evaluating the results screamed when we read her answer , and we did not pursue her further .
I used to complain that programmers simply did n't give a shit about learning beyond the querying aspects of the RDBMS , which kept us at the mercy of overpaid DBAs .
Now ? Now we are starting to see that programmers do n't even give a shit about learning how to query .</tokentext>
<sentencetext>As a web programmer, I wanted to take offense at your statement, but something that happened to me only a few weeks ago is making me have a hell of a lot less faith about the available pool of web programmers out there:During a round of interviews, we sent out a take-home quiz.
We mostly wanted to know if the candidates either knew the actual answers, or could at least google it.
One of the questions involved simple aggregates in SQL.
Given a table with a unique id and a date of birth, I wanted a query that would produce a list of the months of the year, and how many unique records had a DOB that fell on that month.
It's a one-liner.One of my candidates wrote TWELVE counting queries, each one counting DOBs between the (hardcoded) start and end of each month, then she used UNION to make it send out the 12 one-row queries as one 12-row query.Both of us evaluating the results screamed when we read her answer, and we did not pursue her further.
I used to complain that programmers simply didn't give a shit about learning beyond the querying aspects of the RDBMS, which kept us at the mercy of overpaid DBAs.
Now? Now we are starting to see that programmers don't even give a shit about learning how to query.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566045</id>
	<title>Re:Flat Earth</title>
	<author>Threni</author>
	<datestamp>1246537500000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>&gt; Second, SQL hasn't caused people to stop using spreadsheets or Access databases</p><p>If if weren't for SQL there wouldn't be any Access databases...</p></htmltext>
<tokenext>&gt; Second , SQL has n't caused people to stop using spreadsheets or Access databasesIf if were n't for SQL there would n't be any Access databases.. .</tokentext>
<sentencetext>&gt; Second, SQL hasn't caused people to stop using spreadsheets or Access databasesIf if weren't for SQL there wouldn't be any Access databases...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571647</id>
	<title>Re:I don't understand</title>
	<author>Anonymous</author>
	<datestamp>1246635960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>So a bunch of Excel users got together for dinner in San Francisco - why is this news?</p></div><p>exactly<nobr> <wbr></nobr>;)</p></div>
	</htmltext>
<tokenext>So a bunch of Excel users got together for dinner in San Francisco - why is this news ? exactly ; )</tokentext>
<sentencetext>So a bunch of Excel users got together for dinner in San Francisco - why is this news?exactly ;)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566919</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565919</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>caerwyn</author>
	<datestamp>1246536840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.</p></div><p>Grouping on a computed field is quite easy, so if you're waiting for SQL to support it... you've been waiting too long, it already does.</p><p>As for running sums, that's the sort of thing that Oracle already has and just went into the Postgres 8.4 release that was on slashdot the other day.</p><p>Your SQL complaints are a bit out of date.<nobr> <wbr></nobr>:)</p></div>
	</htmltext>
<tokenext>Also , I 'd like to see stuff which is not easily expressed in relational algebra , like running sums or grouping on a computed field.Grouping on a computed field is quite easy , so if you 're waiting for SQL to support it... you 've been waiting too long , it already does.As for running sums , that 's the sort of thing that Oracle already has and just went into the Postgres 8.4 release that was on slashdot the other day.Your SQL complaints are a bit out of date .
: )</tokentext>
<sentencetext>Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.Grouping on a computed field is quite easy, so if you're waiting for SQL to support it... you've been waiting too long, it already does.As for running sums, that's the sort of thing that Oracle already has and just went into the Postgres 8.4 release that was on slashdot the other day.Your SQL complaints are a bit out of date.
:)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566973</id>
	<title>Nested sets</title>
	<author>tepples</author>
	<datestamp>1246543560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Trees is a wellknown problem of SQL</p></div><p>And the "nested set" representation of a tree, <a href="http://www.intelligententerprise.com/001020/celko.jhtml" title="intelligen...rprise.com">explained by Joe Celko</a> [intelligen...rprise.com], is a well-known solution. Give each node an ID making sure that the IDs' collation is pre-order, and then in each node, store the ID of its first and last descendants. So node B is A's descendant if <tt>A.firstdesc &lt;= B.nodeid AND B.nodeid &lt;= A.lastdesc</tt>. There are some situations where <tt>INSERT</tt> statements can become slow (worst case: O(n)), but planning your ID space carefully can ease those.</p></div>
	</htmltext>
<tokenext>Trees is a wellknown problem of SQLAnd the " nested set " representation of a tree , explained by Joe Celko [ intelligen...rprise.com ] , is a well-known solution .
Give each node an ID making sure that the IDs ' collation is pre-order , and then in each node , store the ID of its first and last descendants .
So node B is A 's descendant if A.firstdesc .
There are some situations where INSERT statements can become slow ( worst case : O ( n ) ) , but planning your ID space carefully can ease those .</tokentext>
<sentencetext>Trees is a wellknown problem of SQLAnd the "nested set" representation of a tree, explained by Joe Celko [intelligen...rprise.com], is a well-known solution.
Give each node an ID making sure that the IDs' collation is pre-order, and then in each node, store the ID of its first and last descendants.
So node B is A's descendant if A.firstdesc .
There are some situations where INSERT statements can become slow (worst case: O(n)), but planning your ID space carefully can ease those.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566203</id>
	<title>Re:Tilting at windmills</title>
	<author>SanityInAnarchy</author>
	<datestamp>1246538460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I bet these people could die in their 90's and people will still be using relational dbs and sql.</p></div><p>They'll probably still be using FORTRAN and COBOL. If your only argument is job security, you win.</p><p><div class="quote"><p>being against sql is just plain dumb.</p></div><p>And making a blanket statement like that is just plain uninformed.</p></div>
	</htmltext>
<tokenext>I bet these people could die in their 90 's and people will still be using relational dbs and sql.They 'll probably still be using FORTRAN and COBOL .
If your only argument is job security , you win.being against sql is just plain dumb.And making a blanket statement like that is just plain uninformed .</tokentext>
<sentencetext>I bet these people could die in their 90's and people will still be using relational dbs and sql.They'll probably still be using FORTRAN and COBOL.
If your only argument is job security, you win.being against sql is just plain dumb.And making a blanket statement like that is just plain uninformed.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567273</id>
	<title>Re:Flat Earth</title>
	<author>hunangarden</author>
	<datestamp>1246545600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The whole thing is just reactionary mumbo-jumbo</p></div><p>Well if by "the whole thing" you mean this<nobr> <wbr></nobr>/. topic then you are right.

Here's some non-reactionary things we could discuss on this topic:
</p><ul>
<li>What are some examples of when a non-RDBMs solution is better than RDBMS and SQL?</li>
<li>What are some examples of the opposite?</li>
<li>Is there a way we can generalize these so that its easier identify the class of problems where each solution would be optimal?</li>
<li>What are some non-SQL/non-RDBMS solutions out there, that are generalizable to a large class of problems, and don't require developers to roll their own system for each different problem?</li>
</ul></div>
	</htmltext>
<tokenext>The whole thing is just reactionary mumbo-jumboWell if by " the whole thing " you mean this / .
topic then you are right .
Here 's some non-reactionary things we could discuss on this topic : What are some examples of when a non-RDBMs solution is better than RDBMS and SQL ?
What are some examples of the opposite ?
Is there a way we can generalize these so that its easier identify the class of problems where each solution would be optimal ?
What are some non-SQL/non-RDBMS solutions out there , that are generalizable to a large class of problems , and do n't require developers to roll their own system for each different problem ?</tokentext>
<sentencetext>The whole thing is just reactionary mumbo-jumboWell if by "the whole thing" you mean this /.
topic then you are right.
Here's some non-reactionary things we could discuss on this topic:

What are some examples of when a non-RDBMs solution is better than RDBMS and SQL?
What are some examples of the opposite?
Is there a way we can generalize these so that its easier identify the class of problems where each solution would be optimal?
What are some non-SQL/non-RDBMS solutions out there, that are generalizable to a large class of problems, and don't require developers to roll their own system for each different problem?

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565345</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566919</id>
	<title>I don't understand</title>
	<author>93 Escort Wagon</author>
	<datestamp>1246543200000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>So a bunch of Excel users got together for dinner in San Francisco - why is this news?</p></htmltext>
<tokenext>So a bunch of Excel users got together for dinner in San Francisco - why is this news ?</tokentext>
<sentencetext>So a bunch of Excel users got together for dinner in San Francisco - why is this news?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565497</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>Anonymous</author>
	<datestamp>1246534440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>The idea of RDB is cool, relational algebra is quite neat. But SQL itself is horrible.</p><p>I'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures. For example, if I want to fetch all customers and all their bids in one query I have to use inner join. And that results in LARGE number of rows (Cartesian product of customers and their bids).</p><p>Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.</p></div><p>If you're getting a Cartesian product from a query like that, either the DB architect was a moron or (most likely) you need to learn about the WHERE clause.</p></div>
	</htmltext>
<tokenext>The idea of RDB is cool , relational algebra is quite neat .
But SQL itself is horrible.I 'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures .
For example , if I want to fetch all customers and all their bids in one query I have to use inner join .
And that results in LARGE number of rows ( Cartesian product of customers and their bids ) .Also , I 'd like to see stuff which is not easily expressed in relational algebra , like running sums or grouping on a computed field.If you 're getting a Cartesian product from a query like that , either the DB architect was a moron or ( most likely ) you need to learn about the WHERE clause .</tokentext>
<sentencetext>The idea of RDB is cool, relational algebra is quite neat.
But SQL itself is horrible.I'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures.
For example, if I want to fetch all customers and all their bids in one query I have to use inner join.
And that results in LARGE number of rows (Cartesian product of customers and their bids).Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.If you're getting a Cartesian product from a query like that, either the DB architect was a moron or (most likely) you need to learn about the WHERE clause.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569111</id>
	<title>Re:A time and place for everything</title>
	<author>TheLink</author>
	<datestamp>1246653120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What do you think about Unison and Postgresql?</p><p><a href="http://harts.net/reece/pubs/2009/unison-UCSF-sfpug.pdf" title="harts.net">http://harts.net/reece/pubs/2009/unison-UCSF-sfpug.pdf</a> [harts.net]</p><p>Video of above presentation:</p><p><a href="http://blog.thebuild.com/sfpug/sfpug-unison-20090311.mov" title="thebuild.com">http://blog.thebuild.com/sfpug/sfpug-unison-20090311.mov</a> [thebuild.com]<br><a href="http://www.vimeo.com/3732938" title="vimeo.com">http://www.vimeo.com/3732938</a> [vimeo.com]</p><p>See also: <a href="http://psb.stanford.edu/psb-online/proceedings/psb09/hart.pdf" title="stanford.edu">http://psb.stanford.edu/psb-online/proceedings/psb09/hart.pdf</a> [stanford.edu]</p><p>Presenter is not very good though in my opinion<nobr> <wbr></nobr>:).</p></htmltext>
<tokenext>What do you think about Unison and Postgresql ? http : //harts.net/reece/pubs/2009/unison-UCSF-sfpug.pdf [ harts.net ] Video of above presentation : http : //blog.thebuild.com/sfpug/sfpug-unison-20090311.mov [ thebuild.com ] http : //www.vimeo.com/3732938 [ vimeo.com ] See also : http : //psb.stanford.edu/psb-online/proceedings/psb09/hart.pdf [ stanford.edu ] Presenter is not very good though in my opinion : ) .</tokentext>
<sentencetext>What do you think about Unison and Postgresql?http://harts.net/reece/pubs/2009/unison-UCSF-sfpug.pdf [harts.net]Video of above presentation:http://blog.thebuild.com/sfpug/sfpug-unison-20090311.mov [thebuild.com]http://www.vimeo.com/3732938 [vimeo.com]See also: http://psb.stanford.edu/psb-online/proceedings/psb09/hart.pdf [stanford.edu]Presenter is not very good though in my opinion :).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565613</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143</id>
	<title>A time and place for everything</title>
	<author>Marillion</author>
	<datestamp>1246532460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>There is a time and place for SQL.  There is a time and place to avoid SQL.
<br>
SQL is great for financial data.  SQL is terrible for genetic data.</htmltext>
<tokenext>There is a time and place for SQL .
There is a time and place to avoid SQL .
SQL is great for financial data .
SQL is terrible for genetic data .</tokentext>
<sentencetext>There is a time and place for SQL.
There is a time and place to avoid SQL.
SQL is great for financial data.
SQL is terrible for genetic data.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565345</id>
	<title>Re:Flat Earth</title>
	<author>MightyMartian</author>
	<datestamp>1246533540000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>The whole thing is just reactionary mumbo-jumbo.  There are kinds of data that relational databases are fantastic for, and kinds of data they're not, and sometimes none of it is exactly perfect.  SQL is actually a pretty damned good, single-purpose language.  It's not hard to learn, and once you learn it, the differences between RDBMS implementations becomes a little like Javascript, just something you have to put up with, not that a lot of people actually have to worry all that much about writing fully-portable SQL queries.</p></htmltext>
<tokenext>The whole thing is just reactionary mumbo-jumbo .
There are kinds of data that relational databases are fantastic for , and kinds of data they 're not , and sometimes none of it is exactly perfect .
SQL is actually a pretty damned good , single-purpose language .
It 's not hard to learn , and once you learn it , the differences between RDBMS implementations becomes a little like Javascript , just something you have to put up with , not that a lot of people actually have to worry all that much about writing fully-portable SQL queries .</tokentext>
<sentencetext>The whole thing is just reactionary mumbo-jumbo.
There are kinds of data that relational databases are fantastic for, and kinds of data they're not, and sometimes none of it is exactly perfect.
SQL is actually a pretty damned good, single-purpose language.
It's not hard to learn, and once you learn it, the differences between RDBMS implementations becomes a little like Javascript, just something you have to put up with, not that a lot of people actually have to worry all that much about writing fully-portable SQL queries.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567017</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246543800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>And to expand on that a little, I think each part of the MVC idiom has it's own domain-specific language because those languages are well-suited to those applications.  An imperative language with an emphasis on objects (e.g., Java) just doesn't do the same thing that a declarative set-theoretical language (SQL) does.  Well, it <em>can</em>, but doing so is a royal pain in the ass.  That same imperative language is also total overkill for defining a layout.  HTML does that job beautifully and simply.
<br> <br>
There are certainly common CS themes running between all three.  We have three languages not because people haven't thought about those things, but because they make our lives easier.
<br> <br>
Whenever I hear people bitching about 'doing away' with SQL, I always wonder what they think is wrong with it.  SQL certainly has some limitations, don't get me wrong, but it is a great language for the vast, vast majority of cases.  If your application is so specialized that SQL isn't appropriate, well, bravo, but that does not mean that the relational database concept is flawed.  Personally, I think if people spent a few moments doing some formal analysis before they built their databases (imagine that, <em>thinking</em> before <em>doing</em>?!), they would find that SQL is a beautiful thing.  If your implementation of SQL doesn't cut the mustard, maybe you just need a better query optimizer?</htmltext>
<tokenext>And to expand on that a little , I think each part of the MVC idiom has it 's own domain-specific language because those languages are well-suited to those applications .
An imperative language with an emphasis on objects ( e.g. , Java ) just does n't do the same thing that a declarative set-theoretical language ( SQL ) does .
Well , it can , but doing so is a royal pain in the ass .
That same imperative language is also total overkill for defining a layout .
HTML does that job beautifully and simply .
There are certainly common CS themes running between all three .
We have three languages not because people have n't thought about those things , but because they make our lives easier .
Whenever I hear people bitching about 'doing away ' with SQL , I always wonder what they think is wrong with it .
SQL certainly has some limitations , do n't get me wrong , but it is a great language for the vast , vast majority of cases .
If your application is so specialized that SQL is n't appropriate , well , bravo , but that does not mean that the relational database concept is flawed .
Personally , I think if people spent a few moments doing some formal analysis before they built their databases ( imagine that , thinking before doing ? !
) , they would find that SQL is a beautiful thing .
If your implementation of SQL does n't cut the mustard , maybe you just need a better query optimizer ?</tokentext>
<sentencetext>And to expand on that a little, I think each part of the MVC idiom has it's own domain-specific language because those languages are well-suited to those applications.
An imperative language with an emphasis on objects (e.g., Java) just doesn't do the same thing that a declarative set-theoretical language (SQL) does.
Well, it can, but doing so is a royal pain in the ass.
That same imperative language is also total overkill for defining a layout.
HTML does that job beautifully and simply.
There are certainly common CS themes running between all three.
We have three languages not because people haven't thought about those things, but because they make our lives easier.
Whenever I hear people bitching about 'doing away' with SQL, I always wonder what they think is wrong with it.
SQL certainly has some limitations, don't get me wrong, but it is a great language for the vast, vast majority of cases.
If your application is so specialized that SQL isn't appropriate, well, bravo, but that does not mean that the relational database concept is flawed.
Personally, I think if people spent a few moments doing some formal analysis before they built their databases (imagine that, thinking before doing?!
), they would find that SQL is a beautiful thing.
If your implementation of SQL doesn't cut the mustard, maybe you just need a better query optimizer?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565167</id>
	<title>Protest taxes, not databases</title>
	<author>Anonymous</author>
	<datestamp>1246532640000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext><p>Too bad they can't protest the current regimes taxes with as much enthusiasm.  At least it would be a protest against something that actually matters.</p></htmltext>
<tokenext>Too bad they ca n't protest the current regimes taxes with as much enthusiasm .
At least it would be a protest against something that actually matters .</tokentext>
<sentencetext>Too bad they can't protest the current regimes taxes with as much enthusiasm.
At least it would be a protest against something that actually matters.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569475</id>
	<title>Re:A time and place for everything</title>
	<author>mcrbids</author>
	<datestamp>1246615200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><i>Design an efficient table relating a tree structure. Then design queries to answer questions such as:...</i></p><p>I don't know, but I recall reading that <a href="http://tech.slashdot.org/story/09/07/01/1831250/PostgreSQL-84-Out" title="slashdot.org">Postgres 8.4 is now out and includes support for recursive queries.</a> [slashdot.org] (trees) Not sure about the reputation of the blog in question, but you may have heard of it?</p><p><i>the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones</i></p><p>You are kidding, right? Just today I cooked up a 7-table query including 2 subselects, and a left outer join to a meta table consisting of 2 inner joined tables. Total of some 11 tables comprising a highly complex data set. Don't know what you mean by "very simple one dimensional ones" but 11 tables each joined in either a one-to-many or many-to-many mapping provides at least 11 dimensions. (more if you self-join tabls, often needed) And this isn't particularly hard for me - often I have joins combining 12 or more very large tables with unrestrained combinations somewhere in the billions to trillions of possibilities that all somehow seem to parse just a few seconds thanks to a few well-placed indexes and a well-structured query.</p><p>Methinks you don't really understand SQL?</p></htmltext>
<tokenext>Design an efficient table relating a tree structure .
Then design queries to answer questions such as : ...I do n't know , but I recall reading that Postgres 8.4 is now out and includes support for recursive queries .
[ slashdot.org ] ( trees ) Not sure about the reputation of the blog in question , but you may have heard of it ? the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional onesYou are kidding , right ?
Just today I cooked up a 7-table query including 2 subselects , and a left outer join to a meta table consisting of 2 inner joined tables .
Total of some 11 tables comprising a highly complex data set .
Do n't know what you mean by " very simple one dimensional ones " but 11 tables each joined in either a one-to-many or many-to-many mapping provides at least 11 dimensions .
( more if you self-join tabls , often needed ) And this is n't particularly hard for me - often I have joins combining 12 or more very large tables with unrestrained combinations somewhere in the billions to trillions of possibilities that all somehow seem to parse just a few seconds thanks to a few well-placed indexes and a well-structured query.Methinks you do n't really understand SQL ?</tokentext>
<sentencetext>Design an efficient table relating a tree structure.
Then design queries to answer questions such as:...I don't know, but I recall reading that Postgres 8.4 is now out and includes support for recursive queries.
[slashdot.org] (trees) Not sure about the reputation of the blog in question, but you may have heard of it?the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional onesYou are kidding, right?
Just today I cooked up a 7-table query including 2 subselects, and a left outer join to a meta table consisting of 2 inner joined tables.
Total of some 11 tables comprising a highly complex data set.
Don't know what you mean by "very simple one dimensional ones" but 11 tables each joined in either a one-to-many or many-to-many mapping provides at least 11 dimensions.
(more if you self-join tabls, often needed) And this isn't particularly hard for me - often I have joins combining 12 or more very large tables with unrestrained combinations somewhere in the billions to trillions of possibilities that all somehow seem to parse just a few seconds thanks to a few well-placed indexes and a well-structured query.Methinks you don't really understand SQL?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565593</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>godrik</author>
	<datestamp>1246535040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>For example, if I want to fetch all customers and all their bids in one query I have to use inner join. And that results in LARGE number of rows (Cartesian product of customers and their bids).</p></div><p>I am not sure I get your point. If you do an inner join it means you want all the tuple &lt; player,bid &gt; that makes sense. If there is a lot of them, well, there is a lot of them, there is nothing to do about it. If you complain about each player being repeted on several bid (since they bid more than once). It should not be a problem, as long as you stay in the RBMS, this should not incur any overhead. When you read them, you can just compress them on the fly.</p><p>If you really want to remove those "extra" player values, why do you want to have a single query ? You can just make a query for each player.</p><p><div class="quote"><p>Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.</p></div><p>technically, they cannot be expressed in relationnal algebra, you have to add non algebraic operator to do that. SUM and GROUP BY in SQL are not part of relationnal algrebra. The problem with those operators is that it is difficult to do any optimization on them. Howver, the user may still want to have them. I would also be interested in a language that can express such things efficiently</p></div>
	</htmltext>
<tokenext>For example , if I want to fetch all customers and all their bids in one query I have to use inner join .
And that results in LARGE number of rows ( Cartesian product of customers and their bids ) .I am not sure I get your point .
If you do an inner join it means you want all the tuple that makes sense .
If there is a lot of them , well , there is a lot of them , there is nothing to do about it .
If you complain about each player being repeted on several bid ( since they bid more than once ) .
It should not be a problem , as long as you stay in the RBMS , this should not incur any overhead .
When you read them , you can just compress them on the fly.If you really want to remove those " extra " player values , why do you want to have a single query ?
You can just make a query for each player.Also , I 'd like to see stuff which is not easily expressed in relational algebra , like running sums or grouping on a computed field.technically , they can not be expressed in relationnal algebra , you have to add non algebraic operator to do that .
SUM and GROUP BY in SQL are not part of relationnal algrebra .
The problem with those operators is that it is difficult to do any optimization on them .
Howver , the user may still want to have them .
I would also be interested in a language that can express such things efficiently</tokentext>
<sentencetext>For example, if I want to fetch all customers and all their bids in one query I have to use inner join.
And that results in LARGE number of rows (Cartesian product of customers and their bids).I am not sure I get your point.
If you do an inner join it means you want all the tuple  that makes sense.
If there is a lot of them, well, there is a lot of them, there is nothing to do about it.
If you complain about each player being repeted on several bid (since they bid more than once).
It should not be a problem, as long as you stay in the RBMS, this should not incur any overhead.
When you read them, you can just compress them on the fly.If you really want to remove those "extra" player values, why do you want to have a single query ?
You can just make a query for each player.Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.technically, they cannot be expressed in relationnal algebra, you have to add non algebraic operator to do that.
SUM and GROUP BY in SQL are not part of relationnal algrebra.
The problem with those operators is that it is difficult to do any optimization on them.
Howver, the user may still want to have them.
I would also be interested in a language that can express such things efficiently
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574413</id>
	<title>Re:Quit Whining</title>
	<author>CyberLife</author>
	<datestamp>1246653780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Many application developers need these things<nobr> <wbr></nobr>...</p></div><p>And many do not.</p></div>
	</htmltext>
<tokenext>Many application developers need these things ...And many do not .</tokentext>
<sentencetext>Many application developers need these things ...And many do not.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570711</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246629960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You've designed a structure where *selection* is efficient, but you've forgotten *updates*. These will be very inefficient, as whenever you insert a child node you need to modify a whole bunch of records.</p></htmltext>
<tokenext>You 've designed a structure where * selection * is efficient , but you 've forgotten * updates * .
These will be very inefficient , as whenever you insert a child node you need to modify a whole bunch of records .</tokentext>
<sentencetext>You've designed a structure where *selection* is efficient, but you've forgotten *updates*.
These will be very inefficient, as whenever you insert a child node you need to modify a whole bunch of records.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565869</id>
	<title>Re:Yeah, so why are they better?</title>
	<author>Anonymous</author>
	<datestamp>1246536540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Saying RDMS's map object data well is a bit of a stretch, they map relational data well and that's it.</p><p><a href="http://www.codinghorror.com/blog/archives/000621.html" title="codinghorror.com">http://www.codinghorror.com/blog/archives/000621.html</a> [codinghorror.com] for some good background on the problems.</p><p>For me using an RDMS as the persistence layer for an object-oriented application has ALWAYS felt like a bit of a kludge. Like we're using it just because it's what we have, rather than the best tool for the job.</p></htmltext>
<tokenext>Saying RDMS 's map object data well is a bit of a stretch , they map relational data well and that 's it.http : //www.codinghorror.com/blog/archives/000621.html [ codinghorror.com ] for some good background on the problems.For me using an RDMS as the persistence layer for an object-oriented application has ALWAYS felt like a bit of a kludge .
Like we 're using it just because it 's what we have , rather than the best tool for the job .</tokentext>
<sentencetext>Saying RDMS's map object data well is a bit of a stretch, they map relational data well and that's it.http://www.codinghorror.com/blog/archives/000621.html [codinghorror.com] for some good background on the problems.For me using an RDMS as the persistence layer for an object-oriented application has ALWAYS felt like a bit of a kludge.
Like we're using it just because it's what we have, rather than the best tool for the job.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568953</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246564020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.</p></div><p>http://www.slideshare.net/quipo/trees-in-the-database-advanced-data-structures</p></div>
	</htmltext>
<tokenext>Trees is a wellknown problem of SQL , but the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional ones.http : //www.slideshare.net/quipo/trees-in-the-database-advanced-data-structures</tokentext>
<sentencetext>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.http://www.slideshare.net/quipo/trees-in-the-database-advanced-data-structures
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578125</id>
	<title>Re:Yeah, so why are they better?</title>
	<author>BitZtream</author>
	<datestamp>1246647660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>even the lazy dumb Windows<nobr> <wbr></nobr>.NET programmer doesn't have to strain their brain to learn SQL</p></div></blockquote><p>Fuck you, I'm a lazy<nobr> <wbr></nobr>.NET programmer, but I'm not stupid, most of the time anyway.</p></div>
	</htmltext>
<tokenext>even the lazy dumb Windows .NET programmer does n't have to strain their brain to learn SQLFuck you , I 'm a lazy .NET programmer , but I 'm not stupid , most of the time anyway .</tokentext>
<sentencetext>even the lazy dumb Windows .NET programmer doesn't have to strain their brain to learn SQLFuck you, I'm a lazy .NET programmer, but I'm not stupid, most of the time anyway.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565957</id>
	<title>Unorthodox user of LDAP?</title>
	<author>Zombie Ryushu</author>
	<datestamp>1246537020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>could we see a rise in the use if tree/hirearchial Databases like LDAP?</p></htmltext>
<tokenext>could we see a rise in the use if tree/hirearchial Databases like LDAP ?</tokentext>
<sentencetext>could we see a rise in the use if tree/hirearchial Databases like LDAP?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569811</id>
	<title>My Biggest problem with sql</title>
	<author>TheSunborn</author>
	<datestamp>1246619100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My Biggest problem with sql is that i have defined my database as a graph, but I newer get data back as a graph. Example for slashdot.org:</p><p>There are users, who can post stories and there are comments to each story. Imagine that I want all users that have postet a story, where a comment contains the word Amiga. And I also want the stories, and the comments that contain the word. With sql that's easy, I just do a join between user and story, and between story and comment and take the comments that contain the word amiga.</p><p>No problem, EXCEPT that what I get back is a bag of data with no specific order(And with much redundancy). That's not what I want.</p><p>What I want is a list of users, and for each user I want the stories that he have submitted with at least one comment that contain the given word. And for each story I want the all the comments that contains the word. The sql does contain all the information i need, but extracting it is quite some work.</p><p>My database is defined as a graph where foreign keys are the links, so why does sql(And relational algebra) insist on not using this graph when returning data?</p></htmltext>
<tokenext>My Biggest problem with sql is that i have defined my database as a graph , but I newer get data back as a graph .
Example for slashdot.org : There are users , who can post stories and there are comments to each story .
Imagine that I want all users that have postet a story , where a comment contains the word Amiga .
And I also want the stories , and the comments that contain the word .
With sql that 's easy , I just do a join between user and story , and between story and comment and take the comments that contain the word amiga.No problem , EXCEPT that what I get back is a bag of data with no specific order ( And with much redundancy ) .
That 's not what I want.What I want is a list of users , and for each user I want the stories that he have submitted with at least one comment that contain the given word .
And for each story I want the all the comments that contains the word .
The sql does contain all the information i need , but extracting it is quite some work.My database is defined as a graph where foreign keys are the links , so why does sql ( And relational algebra ) insist on not using this graph when returning data ?</tokentext>
<sentencetext>My Biggest problem with sql is that i have defined my database as a graph, but I newer get data back as a graph.
Example for slashdot.org:There are users, who can post stories and there are comments to each story.
Imagine that I want all users that have postet a story, where a comment contains the word Amiga.
And I also want the stories, and the comments that contain the word.
With sql that's easy, I just do a join between user and story, and between story and comment and take the comments that contain the word amiga.No problem, EXCEPT that what I get back is a bag of data with no specific order(And with much redundancy).
That's not what I want.What I want is a list of users, and for each user I want the stories that he have submitted with at least one comment that contain the given word.
And for each story I want the all the comments that contains the word.
The sql does contain all the information i need, but extracting it is quite some work.My database is defined as a graph where foreign keys are the links, so why does sql(And relational algebra) insist on not using this graph when returning data?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568379</id>
	<title>Re:Pros &amp; Cons of non-relational solutions</title>
	<author>lgw</author>
	<datestamp>1246556400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That was very well put, up to the point of associating Ebay with quality.   There's nothing <i>inherent</i> in, say, key-value-pair databases that makes reporting hard - it's just that people rolling their own solutions often didn't think about that until it was too late.  Massively parallel reporting works as well as massively parallel queries, with a little forethought.</p><p>In the other direction, companies like Visa that have a strong need for data quality seem to scale up, not out, which suggests that there are still difficulties there.  Of course, I'm pretty sure Visa doesn't use a RDB, although I guess they might be using DB2 or something these days.  It's been quite some time since I heard the CIO of Visa speak, but back then they were exploring ways to stop having to write their <i>entire</i> system themselves - but no possible Sun/Oracle cluster was even close.  If you can afford to scale up instead of out, it's really hard to beat running the app and database local to the storage and each other (at which point SQL is pointless, but as you say, SQL != RDB).</p></htmltext>
<tokenext>That was very well put , up to the point of associating Ebay with quality .
There 's nothing inherent in , say , key-value-pair databases that makes reporting hard - it 's just that people rolling their own solutions often did n't think about that until it was too late .
Massively parallel reporting works as well as massively parallel queries , with a little forethought.In the other direction , companies like Visa that have a strong need for data quality seem to scale up , not out , which suggests that there are still difficulties there .
Of course , I 'm pretty sure Visa does n't use a RDB , although I guess they might be using DB2 or something these days .
It 's been quite some time since I heard the CIO of Visa speak , but back then they were exploring ways to stop having to write their entire system themselves - but no possible Sun/Oracle cluster was even close .
If you can afford to scale up instead of out , it 's really hard to beat running the app and database local to the storage and each other ( at which point SQL is pointless , but as you say , SQL ! = RDB ) .</tokentext>
<sentencetext>That was very well put, up to the point of associating Ebay with quality.
There's nothing inherent in, say, key-value-pair databases that makes reporting hard - it's just that people rolling their own solutions often didn't think about that until it was too late.
Massively parallel reporting works as well as massively parallel queries, with a little forethought.In the other direction, companies like Visa that have a strong need for data quality seem to scale up, not out, which suggests that there are still difficulties there.
Of course, I'm pretty sure Visa doesn't use a RDB, although I guess they might be using DB2 or something these days.
It's been quite some time since I heard the CIO of Visa speak, but back then they were exploring ways to stop having to write their entire system themselves - but no possible Sun/Oracle cluster was even close.
If you can afford to scale up instead of out, it's really hard to beat running the app and database local to the storage and each other (at which point SQL is pointless, but as you say, SQL != RDB).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565703</id>
	<title>Re:Yeah, so why are they better?</title>
	<author>spiffmastercow</author>
	<datestamp>1246535640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'd say LINQ is significantly harder to use than SQL most of the time.  The only real exception is when you need to convert the value of a subquery into a comma-delimited list</htmltext>
<tokenext>I 'd say LINQ is significantly harder to use than SQL most of the time .
The only real exception is when you need to convert the value of a subquery into a comma-delimited list</tokentext>
<sentencetext>I'd say LINQ is significantly harder to use than SQL most of the time.
The only real exception is when you need to convert the value of a subquery into a comma-delimited list</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566195</id>
	<title>Re:Quit Whining</title>
	<author>Paradise Pete</author>
	<datestamp>1246538400000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>I"ve lost data in two filesystems thanks to the Slasher's shoddy work.</p></div></blockquote><p>

Have you looked near Redwood Regional Park? On the side of a hill?</p></div>
	</htmltext>
<tokenext>I " ve lost data in two filesystems thanks to the Slasher 's shoddy work .
Have you looked near Redwood Regional Park ?
On the side of a hill ?</tokentext>
<sentencetext>I"ve lost data in two filesystems thanks to the Slasher's shoddy work.
Have you looked near Redwood Regional Park?
On the side of a hill?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565775</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565475</id>
	<title>Except in the in end</title>
	<author>Anonymous</author>
	<datestamp>1246534320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The Patriots themselves levied their own heavy taxes emulating those against which they had originally rebelled<br> <br>
In the end it's all just 1's and 0's.</htmltext>
<tokenext>The Patriots themselves levied their own heavy taxes emulating those against which they had originally rebelled In the end it 's all just 1 's and 0 's .</tokentext>
<sentencetext>The Patriots themselves levied their own heavy taxes emulating those against which they had originally rebelled 
In the end it's all just 1's and 0's.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565727</id>
	<title>Re:Quit Whining</title>
	<author>MichaelSmith</author>
	<datestamp>1246535700000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>This is one of the main objectives of ReiserFS, to make such things easy, a project which unfortunately has run into some difficulty of late.</p></div><p>I wonder if I could sneak Hans an eeepc inside a birthday cake...</p></div>
	</htmltext>
<tokenext>This is one of the main objectives of ReiserFS , to make such things easy , a project which unfortunately has run into some difficulty of late.I wonder if I could sneak Hans an eeepc inside a birthday cake.. .</tokentext>
<sentencetext>This is one of the main objectives of ReiserFS, to make such things easy, a project which unfortunately has run into some difficulty of late.I wonder if I could sneak Hans an eeepc inside a birthday cake...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567355</id>
	<title>Re:A time and place for everything</title>
	<author>smitty\_one\_each</author>
	<datestamp>1246546320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>It seems like a huge chunk of all programming is like being <a href="http://en.wikipedia.org/wiki/Gerardus\_Mercator" title="wikipedia.org">Gerardus Mercator</a> [wikipedia.org].<br>
You've got a bunch of information with one shape, but you really need it in another shape.<br>
The code is about dealing with the embarrassment of it all.<br>
If you've got tabular stuff, and you so very often do, the relational model is fantastic.<br>
If you're dealing with some kind of graph, you're hating life.<br>
People coming in complaining that their aircraft makes a poor submarine are initially amusing, but become tedious.</htmltext>
<tokenext>It seems like a huge chunk of all programming is like being Gerardus Mercator [ wikipedia.org ] .
You 've got a bunch of information with one shape , but you really need it in another shape .
The code is about dealing with the embarrassment of it all .
If you 've got tabular stuff , and you so very often do , the relational model is fantastic .
If you 're dealing with some kind of graph , you 're hating life .
People coming in complaining that their aircraft makes a poor submarine are initially amusing , but become tedious .</tokentext>
<sentencetext>It seems like a huge chunk of all programming is like being Gerardus Mercator [wikipedia.org].
You've got a bunch of information with one shape, but you really need it in another shape.
The code is about dealing with the embarrassment of it all.
If you've got tabular stuff, and you so very often do, the relational model is fantastic.
If you're dealing with some kind of graph, you're hating life.
People coming in complaining that their aircraft makes a poor submarine are initially amusing, but become tedious.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565235</id>
	<title>I've been using text files and Excel</title>
	<author>Anonymous</author>
	<datestamp>1246532880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I keep track of all my car bills and cat names with Notepad and Excel.  I don't know why anyone would need anything more than that.  If I need to sort my text file, I go to this thing called the command line and use the "SORT" command.  If I need to find something in my text file, likewise, I use the command line and the "FIND" command</p></htmltext>
<tokenext>I keep track of all my car bills and cat names with Notepad and Excel .
I do n't know why anyone would need anything more than that .
If I need to sort my text file , I go to this thing called the command line and use the " SORT " command .
If I need to find something in my text file , likewise , I use the command line and the " FIND " command</tokentext>
<sentencetext>I keep track of all my car bills and cat names with Notepad and Excel.
I don't know why anyone would need anything more than that.
If I need to sort my text file, I go to this thing called the command line and use the "SORT" command.
If I need to find something in my text file, likewise, I use the command line and the "FIND" command</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569003</id>
	<title>Re:The problem is performance not SQL</title>
	<author>dannannan</author>
	<datestamp>1246651380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Cheap, unimportant data is not the only factor. A more significant factor is scale. Some of the big "NoSQL" players in TFA have a very real monetary stake in the data they are putting into these systems.</p><p>No one is saying "no to SQL" because they can do without the reliability. Quite the opposite. Put a DBMS under crushing load, and availability is the first thing to go. The big players want a system that is highly available and maintains data integrity.</p><p>A typical DBMS makes strong consistency guarantees across the entire dataset. e.g. After an update is committed, all subsequent reads MUST reflect the change. Turns out this costs a lot; it is a major sacrifice to the potential throughput that could otherwise be achieved with the same hardware, and fundamentally limits the scale of the dataset. Strong consistency adds nothing to reliability and is unnecessary for many apps.</p><p>You are pretty close in your point that when you upload something to Facebook, it doesn't matter if everyone sees it instantly the next time they refresh their browser. That is absolutely true. However this is not to say that the underlying system is lacking in integrity or reliability. An "eventually consistent" data store can reliably guarantee that the data will eventually be reflected in all queries, without requiring it to be resubmitted.</p></htmltext>
<tokenext>Cheap , unimportant data is not the only factor .
A more significant factor is scale .
Some of the big " NoSQL " players in TFA have a very real monetary stake in the data they are putting into these systems.No one is saying " no to SQL " because they can do without the reliability .
Quite the opposite .
Put a DBMS under crushing load , and availability is the first thing to go .
The big players want a system that is highly available and maintains data integrity.A typical DBMS makes strong consistency guarantees across the entire dataset .
e.g. After an update is committed , all subsequent reads MUST reflect the change .
Turns out this costs a lot ; it is a major sacrifice to the potential throughput that could otherwise be achieved with the same hardware , and fundamentally limits the scale of the dataset .
Strong consistency adds nothing to reliability and is unnecessary for many apps.You are pretty close in your point that when you upload something to Facebook , it does n't matter if everyone sees it instantly the next time they refresh their browser .
That is absolutely true .
However this is not to say that the underlying system is lacking in integrity or reliability .
An " eventually consistent " data store can reliably guarantee that the data will eventually be reflected in all queries , without requiring it to be resubmitted .</tokentext>
<sentencetext>Cheap, unimportant data is not the only factor.
A more significant factor is scale.
Some of the big "NoSQL" players in TFA have a very real monetary stake in the data they are putting into these systems.No one is saying "no to SQL" because they can do without the reliability.
Quite the opposite.
Put a DBMS under crushing load, and availability is the first thing to go.
The big players want a system that is highly available and maintains data integrity.A typical DBMS makes strong consistency guarantees across the entire dataset.
e.g. After an update is committed, all subsequent reads MUST reflect the change.
Turns out this costs a lot; it is a major sacrifice to the potential throughput that could otherwise be achieved with the same hardware, and fundamentally limits the scale of the dataset.
Strong consistency adds nothing to reliability and is unnecessary for many apps.You are pretty close in your point that when you upload something to Facebook, it doesn't matter if everyone sees it instantly the next time they refresh their browser.
That is absolutely true.
However this is not to say that the underlying system is lacking in integrity or reliability.
An "eventually consistent" data store can reliably guarantee that the data will eventually be reflected in all queries, without requiring it to be resubmitted.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565955</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568203</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246554300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>faster <b>than</b></htmltext>
<tokenext>faster than</tokentext>
<sentencetext>faster than</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855</id>
	<title>Re:Quit Whining</title>
	<author>jadavis</author>
	<datestamp>1246551420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>One of the reasons is because RDBMSs offer a lot of tools, like atomicity, durability, backup/restore, centralization, point-in-time-recovery, etc. Many application developers need these things without actually needing the abstraction of a relational system.</p></htmltext>
<tokenext>One of the reasons is because RDBMSs offer a lot of tools , like atomicity , durability , backup/restore , centralization , point-in-time-recovery , etc .
Many application developers need these things without actually needing the abstraction of a relational system .</tokentext>
<sentencetext>One of the reasons is because RDBMSs offer a lot of tools, like atomicity, durability, backup/restore, centralization, point-in-time-recovery, etc.
Many application developers need these things without actually needing the abstraction of a relational system.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569379</id>
	<title>Re:Cartesion Product?</title>
	<author>TheThiefMaster</author>
	<datestamp>1246613880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>An "inner join" never results in more rows than are in either table, if you're joining on something that's unique in one table, e.g. customer id.</p><p>No product about it.</p></htmltext>
<tokenext>An " inner join " never results in more rows than are in either table , if you 're joining on something that 's unique in one table , e.g .
customer id.No product about it .</tokentext>
<sentencetext>An "inner join" never results in more rows than are in either table, if you're joining on something that's unique in one table, e.g.
customer id.No product about it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566515</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569945</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246621200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Huh? Tree structures are <i>best</i> handled by relational databases, as it is far faster then recursion. Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.</p></div><p>Great, now tell what would happen when you insert 1.000.000th node on distributed system<nobr> <wbr></nobr>...</p></div>
	</htmltext>
<tokenext>Huh ?
Tree structures are best handled by relational databases , as it is far faster then recursion .
Give row a unique ID and a parent ID , and in addition , a left hand and right hand number , the root node having a left-hand value of 1 and a right hand value of ( number rows * 2 ) , the first child node has a left-hand value of one more than the parent 's , the right-hand value is one less then the left-hand of a younger sibling.Great , now tell what would happen when you insert 1.000.000th node on distributed system .. .</tokentext>
<sentencetext>Huh?
Tree structures are best handled by relational databases, as it is far faster then recursion.
Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.Great, now tell what would happen when you insert 1.000.000th node on distributed system ...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565585</id>
	<title>Re:Flat Earth</title>
	<author>moderatorrater</author>
	<datestamp>1246534980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Agreed. SQL is a generalized solution that works well for a lot of different things and works extremely well for a subset of those thing. For other applications (like indexing the internet), more specialized solutions are going to kick its ass. It's the same way as any programming you do: the easier and more general the tool, the more you sacrifice for it in terms of speed, efficiency, scalability, whatever.</htmltext>
<tokenext>Agreed .
SQL is a generalized solution that works well for a lot of different things and works extremely well for a subset of those thing .
For other applications ( like indexing the internet ) , more specialized solutions are going to kick its ass .
It 's the same way as any programming you do : the easier and more general the tool , the more you sacrifice for it in terms of speed , efficiency , scalability , whatever .</tokentext>
<sentencetext>Agreed.
SQL is a generalized solution that works well for a lot of different things and works extremely well for a subset of those thing.
For other applications (like indexing the internet), more specialized solutions are going to kick its ass.
It's the same way as any programming you do: the easier and more general the tool, the more you sacrifice for it in terms of speed, efficiency, scalability, whatever.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568585</id>
	<title>Re:Quit Whining</title>
	<author>Profane MuthaFucka</author>
	<datestamp>1246559220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I judge a filesystem by its fans. By that measure reiserfs is a fanatic asshole. You can be sure that reiserfs didn't lose your data, and if you say so again you might get yelled at.</p></htmltext>
<tokenext>I judge a filesystem by its fans .
By that measure reiserfs is a fanatic asshole .
You can be sure that reiserfs did n't lose your data , and if you say so again you might get yelled at .</tokentext>
<sentencetext>I judge a filesystem by its fans.
By that measure reiserfs is a fanatic asshole.
You can be sure that reiserfs didn't lose your data, and if you say so again you might get yelled at.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565775</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578153</id>
	<title>Re:Ditch SQL, not Relational DBs!</title>
	<author>BitZtream</author>
	<datestamp>1246648080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>SQL is as standardized as HTML.  Do you suggest we ditch HTML as well?</p><p>Its not that there isn't a standard, its that none of the vendors follow it to the letter.</p><p>This is both good and bad.  Good because pretty much every DB server worth mentioning supports things that are VERY useful and not part of the SQL standard.  Its bad because I can't just switch an app from PostgreSQL to Oracle to MySQL if its anything more than basic queries without rewriting  a lot of those queries.  Okay, you've got a good chance of jumping between Oracle and PostgreSQL, but good luck going between them and MySQL or MSSQL, or any of the others.</p><p>SQL does not suck, it works rather well which is one of the reasons its still here.</p><p>Vendors who don't support the standard to the letter and THEN extend it, suck.</p><p>Don't hate the game, hate the players who don't follow the rules.</p></htmltext>
<tokenext>SQL is as standardized as HTML .
Do you suggest we ditch HTML as well ? Its not that there is n't a standard , its that none of the vendors follow it to the letter.This is both good and bad .
Good because pretty much every DB server worth mentioning supports things that are VERY useful and not part of the SQL standard .
Its bad because I ca n't just switch an app from PostgreSQL to Oracle to MySQL if its anything more than basic queries without rewriting a lot of those queries .
Okay , you 've got a good chance of jumping between Oracle and PostgreSQL , but good luck going between them and MySQL or MSSQL , or any of the others.SQL does not suck , it works rather well which is one of the reasons its still here.Vendors who do n't support the standard to the letter and THEN extend it , suck.Do n't hate the game , hate the players who do n't follow the rules .</tokentext>
<sentencetext>SQL is as standardized as HTML.
Do you suggest we ditch HTML as well?Its not that there isn't a standard, its that none of the vendors follow it to the letter.This is both good and bad.
Good because pretty much every DB server worth mentioning supports things that are VERY useful and not part of the SQL standard.
Its bad because I can't just switch an app from PostgreSQL to Oracle to MySQL if its anything more than basic queries without rewriting  a lot of those queries.
Okay, you've got a good chance of jumping between Oracle and PostgreSQL, but good luck going between them and MySQL or MSSQL, or any of the others.SQL does not suck, it works rather well which is one of the reasons its still here.Vendors who don't support the standard to the letter and THEN extend it, suck.Don't hate the game, hate the players who don't follow the rules.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569301</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567003</id>
	<title>Re:A time and place for everything</title>
	<author>lumbercartel.ca</author>
	<datestamp>1246543680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>PostgreSQL also has specialized index algorithms for handling exotic arrangements of data.  One index type that I'll be looking into in the near future [I've been told] makes it possible to efficiently take two dimensional data, and return rows that all fit within the specified radius starting from two coordinates.  Although this can be done with a combination of indexes and various formulas, it's not as elegant as what PostgreSQL can do now.  So, when I see statements that SQL hasn't progressed, I question the level of expertise of those making such statements.</p><p>As for "all they want is their objects," I think that's true -- just look at all the PHP newbies out there who like to create tables with hundreds of columns instead of taking advantage of one of SQL's greatest hallmarks:  Relationships between tables</p><p>Java (with JDBC) and Perl/mod\_perl/mod\_perl2 (with DBIC, a.k.a., DBIx::Class) should make these folks happy though because they do provide slick OO interfaces to SQL that, unless you keep all your hundred or so columns in a single table, also require at least a basic understanding of SQL.</p><p>Anybody working with databases in a serious way has to have at least a basic understanding of the underlying technology.  Creating an alternative to SQL seems ludicrous to me because it will eventually take away from the large pool of SQL expertise that exists today (I never knew about an anti-SQL movement until I read about it here today on SlashDot); many other alternatives do already exist too, such as BTrieve which has a totally different interface from SQL, and although it performs well it's just not as popular anymore (didn't Pervasive, the company that currently owns the BTrieve technology, switch to a customized rendition of PostgreSQL or something like that anyway?  I wonder what their real reasons were for focusing on SQL in favour of BTrieve?).</p><p>As a developer, I see that performance (speed) is a very important factor, but that's not the only factor for me -- quality of code, helpful documentation, and overall system reliability (including, very importantly, the ability to always recover gracefully from a power outage that occurred while thousands of INSERTs, UPDATEs, and DELETEs are active, which I confirmed in some informal "pull-the-plug" testing many years ago that PostgreSQL and Oracle both do by issuing ROLLBACKs at database mount time after the OS recovers) because it will mean easier development with fewer potential problems for me to deal with in the future if something does fail.</p></htmltext>
<tokenext>PostgreSQL also has specialized index algorithms for handling exotic arrangements of data .
One index type that I 'll be looking into in the near future [ I 've been told ] makes it possible to efficiently take two dimensional data , and return rows that all fit within the specified radius starting from two coordinates .
Although this can be done with a combination of indexes and various formulas , it 's not as elegant as what PostgreSQL can do now .
So , when I see statements that SQL has n't progressed , I question the level of expertise of those making such statements.As for " all they want is their objects , " I think that 's true -- just look at all the PHP newbies out there who like to create tables with hundreds of columns instead of taking advantage of one of SQL 's greatest hallmarks : Relationships between tablesJava ( with JDBC ) and Perl/mod \ _perl/mod \ _perl2 ( with DBIC , a.k.a. , DBIx : : Class ) should make these folks happy though because they do provide slick OO interfaces to SQL that , unless you keep all your hundred or so columns in a single table , also require at least a basic understanding of SQL.Anybody working with databases in a serious way has to have at least a basic understanding of the underlying technology .
Creating an alternative to SQL seems ludicrous to me because it will eventually take away from the large pool of SQL expertise that exists today ( I never knew about an anti-SQL movement until I read about it here today on SlashDot ) ; many other alternatives do already exist too , such as BTrieve which has a totally different interface from SQL , and although it performs well it 's just not as popular anymore ( did n't Pervasive , the company that currently owns the BTrieve technology , switch to a customized rendition of PostgreSQL or something like that anyway ?
I wonder what their real reasons were for focusing on SQL in favour of BTrieve ?
) .As a developer , I see that performance ( speed ) is a very important factor , but that 's not the only factor for me -- quality of code , helpful documentation , and overall system reliability ( including , very importantly , the ability to always recover gracefully from a power outage that occurred while thousands of INSERTs , UPDATEs , and DELETEs are active , which I confirmed in some informal " pull-the-plug " testing many years ago that PostgreSQL and Oracle both do by issuing ROLLBACKs at database mount time after the OS recovers ) because it will mean easier development with fewer potential problems for me to deal with in the future if something does fail .</tokentext>
<sentencetext>PostgreSQL also has specialized index algorithms for handling exotic arrangements of data.
One index type that I'll be looking into in the near future [I've been told] makes it possible to efficiently take two dimensional data, and return rows that all fit within the specified radius starting from two coordinates.
Although this can be done with a combination of indexes and various formulas, it's not as elegant as what PostgreSQL can do now.
So, when I see statements that SQL hasn't progressed, I question the level of expertise of those making such statements.As for "all they want is their objects," I think that's true -- just look at all the PHP newbies out there who like to create tables with hundreds of columns instead of taking advantage of one of SQL's greatest hallmarks:  Relationships between tablesJava (with JDBC) and Perl/mod\_perl/mod\_perl2 (with DBIC, a.k.a., DBIx::Class) should make these folks happy though because they do provide slick OO interfaces to SQL that, unless you keep all your hundred or so columns in a single table, also require at least a basic understanding of SQL.Anybody working with databases in a serious way has to have at least a basic understanding of the underlying technology.
Creating an alternative to SQL seems ludicrous to me because it will eventually take away from the large pool of SQL expertise that exists today (I never knew about an anti-SQL movement until I read about it here today on SlashDot); many other alternatives do already exist too, such as BTrieve which has a totally different interface from SQL, and although it performs well it's just not as popular anymore (didn't Pervasive, the company that currently owns the BTrieve technology, switch to a customized rendition of PostgreSQL or something like that anyway?
I wonder what their real reasons were for focusing on SQL in favour of BTrieve?
).As a developer, I see that performance (speed) is a very important factor, but that's not the only factor for me -- quality of code, helpful documentation, and overall system reliability (including, very importantly, the ability to always recover gracefully from a power outage that occurred while thousands of INSERTs, UPDATEs, and DELETEs are active, which I confirmed in some informal "pull-the-plug" testing many years ago that PostgreSQL and Oracle both do by issuing ROLLBACKs at database mount time after the OS recovers) because it will mean easier development with fewer potential problems for me to deal with in the future if something does fail.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</id>
	<title>RDBs are good, but SQL is horrible</title>
	<author>Anonymous</author>
	<datestamp>1246533720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The idea of RDB is cool, relational algebra is quite neat. But SQL itself is horrible.</p><p>I'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures. For example, if I want to fetch all customers and all their bids in one query I have to use inner join. And that results in LARGE number of rows (Cartesian product of customers and their bids).</p><p>Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.</p></htmltext>
<tokenext>The idea of RDB is cool , relational algebra is quite neat .
But SQL itself is horrible.I 'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures .
For example , if I want to fetch all customers and all their bids in one query I have to use inner join .
And that results in LARGE number of rows ( Cartesian product of customers and their bids ) .Also , I 'd like to see stuff which is not easily expressed in relational algebra , like running sums or grouping on a computed field .</tokentext>
<sentencetext>The idea of RDB is cool, relational algebra is quite neat.
But SQL itself is horrible.I'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures.
For example, if I want to fetch all customers and all their bids in one query I have to use inner join.
And that results in LARGE number of rows (Cartesian product of customers and their bids).Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568787</id>
	<title>Re:A time and place for everything</title>
	<author>shutdown -p now</author>
	<datestamp>1246561740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Microsoft SQL Server 2008 has an interesting take on trees in tables in form of a <a href="http://msdn.microsoft.com/en-us/magazine/cc794278.aspx#id0090187" title="microsoft.com">special data type</a> [microsoft.com] for unique tree node IDs that make relatively efficient queries on ancestors/descendants possible. It does that at a cost of referential integrity, however.</p><p>I'm sure that other major vendors have something in that department, too. There might not be a standard, but "SQL" and "standard compliance" haven't been in the same sentence in practice for the last, what, 15 years or so - so it's not really any different than countless variations on other common things (such as autogenerated PK).</p></htmltext>
<tokenext>Microsoft SQL Server 2008 has an interesting take on trees in tables in form of a special data type [ microsoft.com ] for unique tree node IDs that make relatively efficient queries on ancestors/descendants possible .
It does that at a cost of referential integrity , however.I 'm sure that other major vendors have something in that department , too .
There might not be a standard , but " SQL " and " standard compliance " have n't been in the same sentence in practice for the last , what , 15 years or so - so it 's not really any different than countless variations on other common things ( such as autogenerated PK ) .</tokentext>
<sentencetext>Microsoft SQL Server 2008 has an interesting take on trees in tables in form of a special data type [microsoft.com] for unique tree node IDs that make relatively efficient queries on ancestors/descendants possible.
It does that at a cost of referential integrity, however.I'm sure that other major vendors have something in that department, too.
There might not be a standard, but "SQL" and "standard compliance" haven't been in the same sentence in practice for the last, what, 15 years or so - so it's not really any different than countless variations on other common things (such as autogenerated PK).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28584039</id>
	<title>Parent is right on the money!!!</title>
	<author>dooguls</author>
	<datestamp>1246722360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I just spent 3 months doing cloud computing where we used a 'columner database' similar to <a href="http://labs.google.com/papers/bigtable.html" title="google.com" rel="nofollow">big table</a> [google.com]. We got around the problems because the database was auto indexed lexigraphically by key and we'd make up different keys to help us index the data to find various 'cells' of data quickly and easily. It was beautiful because if we decided a day later that we wanted a new column, we just changed our keys to include the new column and it was there. That way we could quickly prototype, eventually settle on good 'table structure' for lack of a better term, and we could withdraw results very quickly. We could also add new columns much later if we needed to, like if we wanted to store totally different types of data in the same tables later.<br> <br>
The downside to this database is that its very inefficient for rapid transactions. So you would never use it for something like ebay, where the records change 'status' (from for sale to sold). But you could easily use it for something like craigslist or google which stores \_\_lots\_\_ of data that doesn't change.</htmltext>
<tokenext>I just spent 3 months doing cloud computing where we used a 'columner database ' similar to big table [ google.com ] .
We got around the problems because the database was auto indexed lexigraphically by key and we 'd make up different keys to help us index the data to find various 'cells ' of data quickly and easily .
It was beautiful because if we decided a day later that we wanted a new column , we just changed our keys to include the new column and it was there .
That way we could quickly prototype , eventually settle on good 'table structure ' for lack of a better term , and we could withdraw results very quickly .
We could also add new columns much later if we needed to , like if we wanted to store totally different types of data in the same tables later .
The downside to this database is that its very inefficient for rapid transactions .
So you would never use it for something like ebay , where the records change 'status ' ( from for sale to sold ) .
But you could easily use it for something like craigslist or google which stores \ _ \ _lots \ _ \ _ of data that does n't change .</tokentext>
<sentencetext>I just spent 3 months doing cloud computing where we used a 'columner database' similar to big table [google.com].
We got around the problems because the database was auto indexed lexigraphically by key and we'd make up different keys to help us index the data to find various 'cells' of data quickly and easily.
It was beautiful because if we decided a day later that we wanted a new column, we just changed our keys to include the new column and it was there.
That way we could quickly prototype, eventually settle on good 'table structure' for lack of a better term, and we could withdraw results very quickly.
We could also add new columns much later if we needed to, like if we wanted to store totally different types of data in the same tables later.
The downside to this database is that its very inefficient for rapid transactions.
So you would never use it for something like ebay, where the records change 'status' (from for sale to sold).
But you could easily use it for something like craigslist or google which stores \_\_lots\_\_ of data that doesn't change.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565613</id>
	<title>Re:A time and place for everything</title>
	<author>Marillion</author>
	<datestamp>1246535160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Genetic sequences are long strings alphabetic characters.  One of the most common representations is the <a href="http://en.wikipedia.org/wiki/FASTA\_format" title="wikipedia.org">FASTA</a> [wikipedia.org] which deals with the most common type of nucleotide polymorphisms.  You can't use exact string searching to find a match which makes BLOBS and CLOBS useless.  That said, the meta-data of genetic data is reasonably structured and does load into relational databases fairly well.</htmltext>
<tokenext>Genetic sequences are long strings alphabetic characters .
One of the most common representations is the FASTA [ wikipedia.org ] which deals with the most common type of nucleotide polymorphisms .
You ca n't use exact string searching to find a match which makes BLOBS and CLOBS useless .
That said , the meta-data of genetic data is reasonably structured and does load into relational databases fairly well .</tokentext>
<sentencetext>Genetic sequences are long strings alphabetic characters.
One of the most common representations is the FASTA [wikipedia.org] which deals with the most common type of nucleotide polymorphisms.
You can't use exact string searching to find a match which makes BLOBS and CLOBS useless.
That said, the meta-data of genetic data is reasonably structured and does load into relational databases fairly well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566515</id>
	<title>Re:Cartesion Product?</title>
	<author>Cyberax</author>
	<datestamp>1246540260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Nope. It DOES result in a Cartesian product of tuples.</p><p>Notice, I never said that it results in a Cartesian product of the whole tables.</p></htmltext>
<tokenext>Nope .
It DOES result in a Cartesian product of tuples.Notice , I never said that it results in a Cartesian product of the whole tables .</tokentext>
<sentencetext>Nope.
It DOES result in a Cartesian product of tuples.Notice, I never said that it results in a Cartesian product of the whole tables.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565941</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565557</id>
	<title>Whatever</title>
	<author>Anonymous</author>
	<datestamp>1246534800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Like unix being dead - someone else thinks SQL is dead and worthless.</p><p>I disagree, there is no ONE solution. SQL works great for many types of data access. But an object based db can be great for other types.</p><p>SQL is dead. Long live SQL.<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>Like unix being dead - someone else thinks SQL is dead and worthless.I disagree , there is no ONE solution .
SQL works great for many types of data access .
But an object based db can be great for other types.SQL is dead .
Long live SQL .
: - )</tokentext>
<sentencetext>Like unix being dead - someone else thinks SQL is dead and worthless.I disagree, there is no ONE solution.
SQL works great for many types of data access.
But an object based db can be great for other types.SQL is dead.
Long live SQL.
:-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567905</id>
	<title>Re:A time and place for everything</title>
	<author>aztracker1</author>
	<datestamp>1246551720000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>&gt;&gt; Find all ancesters of G</p><p>&gt; SELECT * FROM rows WHERE left  [right hand value of G]</p><p>Now promote a tree node so it's before G...</p></htmltext>
<tokenext>&gt; &gt; Find all ancesters of G &gt; SELECT * FROM rows WHERE left [ right hand value of G ] Now promote a tree node so it 's before G.. .</tokentext>
<sentencetext>&gt;&gt; Find all ancesters of G&gt; SELECT * FROM rows WHERE left  [right hand value of G]Now promote a tree node so it's before G...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570079</id>
	<title>Re:Been there, done that already!</title>
	<author>itsybitsy</author>
	<datestamp>1246623660000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>[meta]How the heck can the parent comment be flame bait? You have a posting about a "new" anti-sql approach that has been done N times before where N is a very large number being passed off as "new" and then you don't like a comment that point that out? WTF? It's not flamebait, it's a dissident's comment. I most certainly support their efforts to promote anti-sql agendas. I was merely pointing out that it's been done before. Oh, and I use Relational Databases and SQL all the time. I've also written object to relational mapping layers that have actually worked with transactions in memory! So I know of what I speak, which I doubt of the moderators as they are clearly blind. In fact why can't we see who moderated? Why can't we see all the ratings for a post? If someone moderates a post up as interesting why can't we see that too? The moderation system here at slashdot sucks big time for it's highly denigrating to those of us who attempt to share our hard earned wisdom. Sigh.[/meta]</p></htmltext>
<tokenext>[ meta ] How the heck can the parent comment be flame bait ?
You have a posting about a " new " anti-sql approach that has been done N times before where N is a very large number being passed off as " new " and then you do n't like a comment that point that out ?
WTF ? It 's not flamebait , it 's a dissident 's comment .
I most certainly support their efforts to promote anti-sql agendas .
I was merely pointing out that it 's been done before .
Oh , and I use Relational Databases and SQL all the time .
I 've also written object to relational mapping layers that have actually worked with transactions in memory !
So I know of what I speak , which I doubt of the moderators as they are clearly blind .
In fact why ca n't we see who moderated ?
Why ca n't we see all the ratings for a post ?
If someone moderates a post up as interesting why ca n't we see that too ?
The moderation system here at slashdot sucks big time for it 's highly denigrating to those of us who attempt to share our hard earned wisdom .
Sigh. [ /meta ]</tokentext>
<sentencetext>[meta]How the heck can the parent comment be flame bait?
You have a posting about a "new" anti-sql approach that has been done N times before where N is a very large number being passed off as "new" and then you don't like a comment that point that out?
WTF? It's not flamebait, it's a dissident's comment.
I most certainly support their efforts to promote anti-sql agendas.
I was merely pointing out that it's been done before.
Oh, and I use Relational Databases and SQL all the time.
I've also written object to relational mapping layers that have actually worked with transactions in memory!
So I know of what I speak, which I doubt of the moderators as they are clearly blind.
In fact why can't we see who moderated?
Why can't we see all the ratings for a post?
If someone moderates a post up as interesting why can't we see that too?
The moderation system here at slashdot sucks big time for it's highly denigrating to those of us who attempt to share our hard earned wisdom.
Sigh.[/meta]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568261</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567427</id>
	<title>Hash tables, caches and time sequences...</title>
	<author>flyingfsck</author>
	<datestamp>1246546920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I must be getting old, but there are many types of simple table based systems around and they used in things like sendmail, postfix, squid-cache, round robin database, look aside tables, computer instruction caches and so on.  This istuff is nothing new.  It is a matter of using the right tool for the job without the need to consult an oracle.</htmltext>
<tokenext>I must be getting old , but there are many types of simple table based systems around and they used in things like sendmail , postfix , squid-cache , round robin database , look aside tables , computer instruction caches and so on .
This istuff is nothing new .
It is a matter of using the right tool for the job without the need to consult an oracle .</tokentext>
<sentencetext>I must be getting old, but there are many types of simple table based systems around and they used in things like sendmail, postfix, squid-cache, round robin database, look aside tables, computer instruction caches and so on.
This istuff is nothing new.
It is a matter of using the right tool for the job without the need to consult an oracle.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567643</id>
	<title>Re:A time and place for everything</title>
	<author>lawpoop</author>
	<datestamp>1246549380000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>For anyone wondering, parent is talking about a preorder tree traversal algorithm:

<br> <a href="http://dev.mysql.com/tech-resources/articles/hierarchical-data.html" title="mysql.com">Link 1</a> [mysql.com]

<br> <a href="http://www.sitepoint.com/article/hierarchical-data-database/2/" title="sitepoint.com">Link 2</a> [sitepoint.com] <br> <br>And parent it right. I was doing an adjacency list in MySQL for a while, because I thought that preorder trees were just a little too complicated, but they are *way* easier and more intuitive.</htmltext>
<tokenext>For anyone wondering , parent is talking about a preorder tree traversal algorithm : Link 1 [ mysql.com ] Link 2 [ sitepoint.com ] And parent it right .
I was doing an adjacency list in MySQL for a while , because I thought that preorder trees were just a little too complicated , but they are * way * easier and more intuitive .</tokentext>
<sentencetext>For anyone wondering, parent is talking about a preorder tree traversal algorithm:

 Link 1 [mysql.com]

 Link 2 [sitepoint.com]  And parent it right.
I was doing an adjacency list in MySQL for a while, because I thought that preorder trees were just a little too complicated, but they are *way* easier and more intuitive.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570329</id>
	<title>Re:A time and place for everything</title>
	<author>TheRaven64</author>
	<datestamp>1246626900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think this illustrates the problem with SQL.  You have to design your database for the type of query you want to run.  For example, try writing an arbitrary transitive closure in SQL.  You can't, unless you specifically stored your data in a form that computes this on insert.  </p><p>
This is fine, except that requirements change over time.  It's very easy to get into a situation where the queries you want to run are painfully slow on the data layout you have.  Your only solution is to move the data to a brand new schema.  SQL, however, doesn't encourage the kind of abstraction that makes this kind of refactoring easy.</p><p>
When I evaluate a programming language, one of my main criteria is how easy it is to adapt code written by an average (i.e. not very good) programmer to a new set of requirements.  SQL does very badly here.  </p><p>
If you have good SQL programmers / database architects and you have a set of requirements that aren't likely to change much over time, you can do some great things with SQL.  Unfortunately, this isn't a luxury most of us have.</p></htmltext>
<tokenext>I think this illustrates the problem with SQL .
You have to design your database for the type of query you want to run .
For example , try writing an arbitrary transitive closure in SQL .
You ca n't , unless you specifically stored your data in a form that computes this on insert .
This is fine , except that requirements change over time .
It 's very easy to get into a situation where the queries you want to run are painfully slow on the data layout you have .
Your only solution is to move the data to a brand new schema .
SQL , however , does n't encourage the kind of abstraction that makes this kind of refactoring easy .
When I evaluate a programming language , one of my main criteria is how easy it is to adapt code written by an average ( i.e .
not very good ) programmer to a new set of requirements .
SQL does very badly here .
If you have good SQL programmers / database architects and you have a set of requirements that are n't likely to change much over time , you can do some great things with SQL .
Unfortunately , this is n't a luxury most of us have .</tokentext>
<sentencetext>I think this illustrates the problem with SQL.
You have to design your database for the type of query you want to run.
For example, try writing an arbitrary transitive closure in SQL.
You can't, unless you specifically stored your data in a form that computes this on insert.
This is fine, except that requirements change over time.
It's very easy to get into a situation where the queries you want to run are painfully slow on the data layout you have.
Your only solution is to move the data to a brand new schema.
SQL, however, doesn't encourage the kind of abstraction that makes this kind of refactoring easy.
When I evaluate a programming language, one of my main criteria is how easy it is to adapt code written by an average (i.e.
not very good) programmer to a new set of requirements.
SQL does very badly here.
If you have good SQL programmers / database architects and you have a set of requirements that aren't likely to change much over time, you can do some great things with SQL.
Unfortunately, this isn't a luxury most of us have.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565797</id>
	<title>forgotten revolution</title>
	<author>MaoTse</author>
	<datestamp>1246536120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><a href="http://www.zope.org/" title="zope.org" rel="nofollow">http://www.zope.org/</a> [zope.org] - both WLS and hibernate made obsolete decade ago<br>that "both" - unfortunetaly the case when too much is too much<nobr> <wbr></nobr>;-)</p></htmltext>
<tokenext>http : //www.zope.org/ [ zope.org ] - both WLS and hibernate made obsolete decade agothat " both " - unfortunetaly the case when too much is too much ; - )</tokentext>
<sentencetext>http://www.zope.org/ [zope.org] - both WLS and hibernate made obsolete decade agothat "both" - unfortunetaly the case when too much is too much ;-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565941</id>
	<title>Cartesion Product?</title>
	<author>gbutler69</author>
	<datestamp>1246536960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Epic Fail. You're wrong. It in now way results in a "Cartesion Product". That would be a "Cross Join", not an "inner join". From my experience, people who complain about SQL and relational database, are, for the most part, ignorant. They really don't even understand what they are saying or what they are talking about. I've seen so much abuse and misunderstanding of relational data and SQL in my career, that I just have to laugh at this sort of thing.</htmltext>
<tokenext>Epic Fail .
You 're wrong .
It in now way results in a " Cartesion Product " .
That would be a " Cross Join " , not an " inner join " .
From my experience , people who complain about SQL and relational database , are , for the most part , ignorant .
They really do n't even understand what they are saying or what they are talking about .
I 've seen so much abuse and misunderstanding of relational data and SQL in my career , that I just have to laugh at this sort of thing .</tokentext>
<sentencetext>Epic Fail.
You're wrong.
It in now way results in a "Cartesion Product".
That would be a "Cross Join", not an "inner join".
From my experience, people who complain about SQL and relational database, are, for the most part, ignorant.
They really don't even understand what they are saying or what they are talking about.
I've seen so much abuse and misunderstanding of relational data and SQL in my career, that I just have to laugh at this sort of thing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567609</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246548960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's nice.</p><p>How do you find the *immediate* children of a node?</p><p>How do you insert into this?</p><p>What do you do when you blow your right hand value?</p><p>And let's not forget that your "efficient" implementation transforms a O(depth)=O(log n) operation (finding the ancestry) into a O(n) merge.</p></htmltext>
<tokenext>That 's nice.How do you find the * immediate * children of a node ? How do you insert into this ? What do you do when you blow your right hand value ? And let 's not forget that your " efficient " implementation transforms a O ( depth ) = O ( log n ) operation ( finding the ancestry ) into a O ( n ) merge .</tokentext>
<sentencetext>That's nice.How do you find the *immediate* children of a node?How do you insert into this?What do you do when you blow your right hand value?And let's not forget that your "efficient" implementation transforms a O(depth)=O(log n) operation (finding the ancestry) into a O(n) merge.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574729</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>colinrichardday</author>
	<datestamp>1246612980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Take two "tables" of ordered pairs: {(2, 5), (8, 7), (3, 1)} and {(5 , 9), (4, 3), (7, 5)}. If we do an inner join between the two tables, looking for where the second coordinate of data from the first table matches the first coordinate of data from the second table and then return the first coordinate of data from the first table with the second coordinate of data from the second table, we get {(2,9), (8, 5)}. Inner joins are more like composition of relations.</p></htmltext>
<tokenext>Take two " tables " of ordered pairs : { ( 2 , 5 ) , ( 8 , 7 ) , ( 3 , 1 ) } and { ( 5 , 9 ) , ( 4 , 3 ) , ( 7 , 5 ) } .
If we do an inner join between the two tables , looking for where the second coordinate of data from the first table matches the first coordinate of data from the second table and then return the first coordinate of data from the first table with the second coordinate of data from the second table , we get { ( 2,9 ) , ( 8 , 5 ) } .
Inner joins are more like composition of relations .</tokentext>
<sentencetext>Take two "tables" of ordered pairs: {(2, 5), (8, 7), (3, 1)} and {(5 , 9), (4, 3), (7, 5)}.
If we do an inner join between the two tables, looking for where the second coordinate of data from the first table matches the first coordinate of data from the second table and then return the first coordinate of data from the first table with the second coordinate of data from the second table, we get {(2,9), (8, 5)}.
Inner joins are more like composition of relations.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568261</id>
	<title>Been there, done that already!</title>
	<author>itsybitsy</author>
	<datestamp>1246554960000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>1</modscore>
	<htmltext><p>Dah! Everyone with any technical skills has known for many decades that relational database are junk. Sure they do a particular job but then so does a swiss army knife but you'd not use it to cut a forest down you'd get a proper volume tool and nothing beats object databases with a simple file structure. Flat files are great too however they tend to require extra parsing slowing things down. You can roll your own object database system easily even with full on transactions and concurrency support in under a man month. Death to Relational Databases.</p></htmltext>
<tokenext>Dah !
Everyone with any technical skills has known for many decades that relational database are junk .
Sure they do a particular job but then so does a swiss army knife but you 'd not use it to cut a forest down you 'd get a proper volume tool and nothing beats object databases with a simple file structure .
Flat files are great too however they tend to require extra parsing slowing things down .
You can roll your own object database system easily even with full on transactions and concurrency support in under a man month .
Death to Relational Databases .</tokentext>
<sentencetext>Dah!
Everyone with any technical skills has known for many decades that relational database are junk.
Sure they do a particular job but then so does a swiss army knife but you'd not use it to cut a forest down you'd get a proper volume tool and nothing beats object databases with a simple file structure.
Flat files are great too however they tend to require extra parsing slowing things down.
You can roll your own object database system easily even with full on transactions and concurrency support in under a man month.
Death to Relational Databases.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570779</id>
	<title>SQl works</title>
	<author>nurb432</author>
	<datestamp>1246630380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And works well.  Let them go off on their own and play around, and let the rest of us get some work done.</p><p>What is next, complaining that wheels aren't the coolest way to get around town?</p></htmltext>
<tokenext>And works well .
Let them go off on their own and play around , and let the rest of us get some work done.What is next , complaining that wheels are n't the coolest way to get around town ?</tokentext>
<sentencetext>And works well.
Let them go off on their own and play around, and let the rest of us get some work done.What is next, complaining that wheels aren't the coolest way to get around town?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569765</id>
	<title>Re:Yeah, so why are they better?</title>
	<author>jawahar</author>
	<datestamp>1246618560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>I bet somewhere someone would be wittering on about Key Value Datastores.</p></div></blockquote><p>
I believe there is a trivial difference between <b>SQL</b> and <b>Key Value Datastores</b> if both the APPLICATION and complete DATA are loaded into RAM (the way Google does).</p></div>
	</htmltext>
<tokenext>I bet somewhere someone would be wittering on about Key Value Datastores .
I believe there is a trivial difference between SQL and Key Value Datastores if both the APPLICATION and complete DATA are loaded into RAM ( the way Google does ) .</tokentext>
<sentencetext>I bet somewhere someone would be wittering on about Key Value Datastores.
I believe there is a trivial difference between SQL and Key Value Datastores if both the APPLICATION and complete DATA are loaded into RAM (the way Google does).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568305</id>
	<title>Re:Quit Whining</title>
	<author>knightghost</author>
	<datestamp>1246555260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"The right tool for the job" is always worth striving for.  However, rhetoric such as "tyranny of slow, expensive relational databases" merely shows incompetence when it comes to understanding what a database is.  If you have structured data then there is nothing more efficient, effective, or faster than a relational database.  For unstructured data, go Google indexing or Perl heaps.</htmltext>
<tokenext>" The right tool for the job " is always worth striving for .
However , rhetoric such as " tyranny of slow , expensive relational databases " merely shows incompetence when it comes to understanding what a database is .
If you have structured data then there is nothing more efficient , effective , or faster than a relational database .
For unstructured data , go Google indexing or Perl heaps .</tokentext>
<sentencetext>"The right tool for the job" is always worth striving for.
However, rhetoric such as "tyranny of slow, expensive relational databases" merely shows incompetence when it comes to understanding what a database is.
If you have structured data then there is nothing more efficient, effective, or faster than a relational database.
For unstructured data, go Google indexing or Perl heaps.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568847</id>
	<title>Re:A time and place for everything</title>
	<author>slashdotwannabe</author>
	<datestamp>1246562520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I want to say you're breaking fourth normal form, but I can't.</p><p>I want to say you're storing derived data, but I can't.</p><p>I CAN say that data structure is just butt-ass-ugly.</p></htmltext>
<tokenext>I want to say you 're breaking fourth normal form , but I ca n't.I want to say you 're storing derived data , but I ca n't.I CAN say that data structure is just butt-ass-ugly .</tokentext>
<sentencetext>I want to say you're breaking fourth normal form, but I can't.I want to say you're storing derived data, but I can't.I CAN say that data structure is just butt-ass-ugly.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629</id>
	<title>Re:Quit Whining</title>
	<author>Mjec</author>
	<datestamp>1246616520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If your data isn't complex enough to require a RDBMS, you almost certainly don't need a program.</p><p>Ok, so this is an outright lie - if you're storing a list of integers, you don't need a relational database. But what <em>I'm</em> tired of is people not understanding their data. A LOT of data is relational and proper, normalised storage is generally non-trivial. Of course, well-structured data leads to a well-structured program leads to fun buzzwords like extensibility.</p></htmltext>
<tokenext>If your data is n't complex enough to require a RDBMS , you almost certainly do n't need a program.Ok , so this is an outright lie - if you 're storing a list of integers , you do n't need a relational database .
But what I 'm tired of is people not understanding their data .
A LOT of data is relational and proper , normalised storage is generally non-trivial .
Of course , well-structured data leads to a well-structured program leads to fun buzzwords like extensibility .</tokentext>
<sentencetext>If your data isn't complex enough to require a RDBMS, you almost certainly don't need a program.Ok, so this is an outright lie - if you're storing a list of integers, you don't need a relational database.
But what I'm tired of is people not understanding their data.
A LOT of data is relational and proper, normalised storage is generally non-trivial.
Of course, well-structured data leads to a well-structured program leads to fun buzzwords like extensibility.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566373</id>
	<title>Re:Yeah, so why are they better?</title>
	<author>Skapare</author>
	<datestamp>1246539420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>SQL can do just about everything you need in a data store<nobr> <wbr></nobr>... if you aren't considering performance and cost.  For many things, the whole point is that SQL is overkill.  The alternative solves FEWER problems<nobr> <wbr></nobr>... it just solves them BETTER.</p></htmltext>
<tokenext>SQL can do just about everything you need in a data store ... if you are n't considering performance and cost .
For many things , the whole point is that SQL is overkill .
The alternative solves FEWER problems ... it just solves them BETTER .</tokentext>
<sentencetext>SQL can do just about everything you need in a data store ... if you aren't considering performance and cost.
For many things, the whole point is that SQL is overkill.
The alternative solves FEWER problems ... it just solves them BETTER.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28583351</id>
	<title>Re:Pros &amp; Cons of non-relational solutions</title>
	<author>Anonymous</author>
	<datestamp>1246712100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You need better developers.</p></htmltext>
<tokenext>You need better developers .</tokentext>
<sentencetext>You need better developers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565269</id>
	<title>Next  Up...</title>
	<author>grepya</author>
	<datestamp>1246533120000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p>...say no to the tyranny of... er.. English. Let's stick with the combination of grunts, squeals, crying and gesturing that has proven so effective for toddlers all over the globe for thousands of years. And if we surrendered the traditional languages that we are so irrationally attached to, who knows what revolutionary new communication scheme the next-generation kids will come up with.</p><p>
&nbsp;</p></htmltext>
<tokenext>...say no to the tyranny of... er.. English .
Let 's stick with the combination of grunts , squeals , crying and gesturing that has proven so effective for toddlers all over the globe for thousands of years .
And if we surrendered the traditional languages that we are so irrationally attached to , who knows what revolutionary new communication scheme the next-generation kids will come up with .
 </tokentext>
<sentencetext>...say no to the tyranny of... er.. English.
Let's stick with the combination of grunts, squeals, crying and gesturing that has proven so effective for toddlers all over the globe for thousands of years.
And if we surrendered the traditional languages that we are so irrationally attached to, who knows what revolutionary new communication scheme the next-generation kids will come up with.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570189</id>
	<title>Re:A time and place for everything</title>
	<author>ukyoCE</author>
	<datestamp>1246624980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think you're confused - HQL and Linq are there to hide the shortcomings of the *developers* (and development frameworks), not of SQL.  They're basically there to try to force bad developers into using an overly-standard methodology, instead of doing things Right and Fast.  You redefine Right to be "however the framework does it", and redfine Fast to be....extremely Slow.</p></htmltext>
<tokenext>I think you 're confused - HQL and Linq are there to hide the shortcomings of the * developers * ( and development frameworks ) , not of SQL .
They 're basically there to try to force bad developers into using an overly-standard methodology , instead of doing things Right and Fast .
You redefine Right to be " however the framework does it " , and redfine Fast to be....extremely Slow .</tokentext>
<sentencetext>I think you're confused - HQL and Linq are there to hide the shortcomings of the *developers* (and development frameworks), not of SQL.
They're basically there to try to force bad developers into using an overly-standard methodology, instead of doing things Right and Fast.
You redefine Right to be "however the framework does it", and redfine Fast to be....extremely Slow.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571577</id>
	<title>Re:SQL is not a database</title>
	<author>Anonymous</author>
	<datestamp>1246635480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The real problem is; SQL isn't standardized, it's only structured.</p></htmltext>
<tokenext>The real problem is ; SQL is n't standardized , it 's only structured .</tokentext>
<sentencetext>The real problem is; SQL isn't standardized, it's only structured.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565627</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565527</id>
	<title>Re:Flat Earth</title>
	<author>Clover\_Kicker</author>
	<datestamp>1246534560000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>You're not going to get many page hits with an attitude like that...</p></htmltext>
<tokenext>You 're not going to get many page hits with an attitude like that.. .</tokentext>
<sentencetext>You're not going to get many page hits with an attitude like that...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566995</id>
	<title>Re:How about saying yes to the alternative</title>
	<author>g2devi</author>
	<datestamp>1246543680000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Sure. There are several.</p><p>If you do clinical work, you're fairly familiar with EAV databases:<br><a href="http://en.wikipedia.org/wiki/Entity-attribute-value\_model" title="wikipedia.org">http://en.wikipedia.org/wiki/Entity-attribute-value\_model</a> [wikipedia.org]</p><p>and The Associative Model of Data:<br><a href="http://www.lazysoft.com/docs/other\_docs/AMD.pdf" title="lazysoft.com">http://www.lazysoft.com/docs/other\_docs/AMD.pdf</a> [lazysoft.com]</p><p>These data models are best when either your schema is inherently hazy (e.g. in case of patient information) of where the schema is so big that it's impossible to manage (e.g. enterprise data warehousing).</p></htmltext>
<tokenext>Sure .
There are several.If you do clinical work , you 're fairly familiar with EAV databases : http : //en.wikipedia.org/wiki/Entity-attribute-value \ _model [ wikipedia.org ] and The Associative Model of Data : http : //www.lazysoft.com/docs/other \ _docs/AMD.pdf [ lazysoft.com ] These data models are best when either your schema is inherently hazy ( e.g .
in case of patient information ) of where the schema is so big that it 's impossible to manage ( e.g .
enterprise data warehousing ) .</tokentext>
<sentencetext>Sure.
There are several.If you do clinical work, you're fairly familiar with EAV databases:http://en.wikipedia.org/wiki/Entity-attribute-value\_model [wikipedia.org]and The Associative Model of Data:http://www.lazysoft.com/docs/other\_docs/AMD.pdf [lazysoft.com]These data models are best when either your schema is inherently hazy (e.g.
in case of patient information) of where the schema is so big that it's impossible to manage (e.g.
enterprise data warehousing).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565535</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570593</id>
	<title>Access is good enough for anything</title>
	<author>FreakyGreenLeaky</author>
	<datestamp>1246629120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm not surprised; these are probably the same class of people who maintain that MS Access is all you need for a high-traffic website backend.<br> <br>

They're also the same class of people who are at a loss to explain why their site/application is so slow under load...<br> <br>

Stupid dummies.<br> <br>

Then again, I haven't RTA, so I'm probably babbling.<br> <br>

Anyway, it's Friday and it's been a long week dealing with fuck'n dummies who don't apologise when shown the error of their ways, so fuckit, fuckthem, fuckemall.  <i>Say ghello to my leetle friend...</i></htmltext>
<tokenext>I 'm not surprised ; these are probably the same class of people who maintain that MS Access is all you need for a high-traffic website backend .
They 're also the same class of people who are at a loss to explain why their site/application is so slow under load.. . Stupid dummies .
Then again , I have n't RTA , so I 'm probably babbling .
Anyway , it 's Friday and it 's been a long week dealing with fuck'n dummies who do n't apologise when shown the error of their ways , so fuckit , fuckthem , fuckemall .
Say ghello to my leetle friend.. .</tokentext>
<sentencetext>I'm not surprised; these are probably the same class of people who maintain that MS Access is all you need for a high-traffic website backend.
They're also the same class of people who are at a loss to explain why their site/application is so slow under load... 

Stupid dummies.
Then again, I haven't RTA, so I'm probably babbling.
Anyway, it's Friday and it's been a long week dealing with fuck'n dummies who don't apologise when shown the error of their ways, so fuckit, fuckthem, fuckemall.
Say ghello to my leetle friend...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572669</id>
	<title>Re:A time and place for everything</title>
	<author>jadavis</author>
	<datestamp>1246642020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>I always wonder what they think is wrong with it.</i></p><p>Most people who think this fall into one or more of the following categories:<br>1. They have specialized needs, very few queries, and don't expect to need more queries or ad-hoc queries later on. Because of this simplicity they have little use for SQL.<br>2. They need the other tools offered by an RDBMS, like backup/restore, atomicity, durability, etc., but for some reason don't want to use SQL (probably due to #1).<br>3. They have narrow complains about the language design of SQL, for instance the ugly natural language syntax that's inflexible and inconsistent. This leads to a general dislike of SQL.<br>4. They don't understand SQL or relational database theory, and would just prefer that it went away.</p></htmltext>
<tokenext>I always wonder what they think is wrong with it.Most people who think this fall into one or more of the following categories : 1 .
They have specialized needs , very few queries , and do n't expect to need more queries or ad-hoc queries later on .
Because of this simplicity they have little use for SQL.2 .
They need the other tools offered by an RDBMS , like backup/restore , atomicity , durability , etc. , but for some reason do n't want to use SQL ( probably due to # 1 ) .3 .
They have narrow complains about the language design of SQL , for instance the ugly natural language syntax that 's inflexible and inconsistent .
This leads to a general dislike of SQL.4 .
They do n't understand SQL or relational database theory , and would just prefer that it went away .</tokentext>
<sentencetext>I always wonder what they think is wrong with it.Most people who think this fall into one or more of the following categories:1.
They have specialized needs, very few queries, and don't expect to need more queries or ad-hoc queries later on.
Because of this simplicity they have little use for SQL.2.
They need the other tools offered by an RDBMS, like backup/restore, atomicity, durability, etc., but for some reason don't want to use SQL (probably due to #1).3.
They have narrow complains about the language design of SQL, for instance the ugly natural language syntax that's inflexible and inconsistent.
This leads to a general dislike of SQL.4.
They don't understand SQL or relational database theory, and would just prefer that it went away.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567017</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571847</id>
	<title>Re:Quit Whining</title>
	<author>umberleigh</author>
	<datestamp>1246636800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>you kid, but I used to work for a db/information management company that was retarded enough to do this.</htmltext>
<tokenext>you kid , but I used to work for a db/information management company that was retarded enough to do this .</tokentext>
<sentencetext>you kid, but I used to work for a db/information management company that was retarded enough to do this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</id>
	<title>Re:A time and place for everything</title>
	<author>diamondmagic</author>
	<datestamp>1246543080000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>Design an efficient table relating a tree structure.</p></div><p>Huh? Tree structures are <i>best</i> handled by relational databases, as it is far faster then recursion. Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.</p><p><div class="quote"><p>Then design queries to answer questions such as:<br>* Find the nodes in the subtree under B.</p></div><p>SELECT * FROM rows WHERE left &gt; [left hand value of B] AND right &lt; [right hand value of B]</p><p><div class="quote"><p>* Find all ancesters of G</p></div><p>SELECT * FROM rows WHERE left &lt; [left hand value of G] AND right &gt; [right hand value of G]</p><p><div class="quote"><p>* Find the nearest common ancestor of D and H</p></div><p>SELECT * FROM rows WHERE left &lt; [lowest left hand value from D,H] AND right &gt; [highest right hand value from D,H] ORDER BY right LIMIT 1</p><p><div class="quote"><p>Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.</p></div><p>Are you saying trees are easy or hard? And for more complex systems, that is what JOINs are for. SQL is by far the most powerful way and often the fastest way to manipulate data that I know of. The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation.</p></div>
	</htmltext>
<tokenext>Design an efficient table relating a tree structure.Huh ?
Tree structures are best handled by relational databases , as it is far faster then recursion .
Give row a unique ID and a parent ID , and in addition , a left hand and right hand number , the root node having a left-hand value of 1 and a right hand value of ( number rows * 2 ) , the first child node has a left-hand value of one more than the parent 's , the right-hand value is one less then the left-hand of a younger sibling.Then design queries to answer questions such as : * Find the nodes in the subtree under B.SELECT * FROM rows WHERE left &gt; [ left hand value of B ] AND right * Find all ancesters of GSELECT * FROM rows WHERE left [ right hand value of G ] * Find the nearest common ancestor of D and HSELECT * FROM rows WHERE left [ highest right hand value from D,H ] ORDER BY right LIMIT 1Trees is a wellknown problem of SQL , but the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional ones.Are you saying trees are easy or hard ?
And for more complex systems , that is what JOINs are for .
SQL is by far the most powerful way and often the fastest way to manipulate data that I know of .
The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation .</tokentext>
<sentencetext>Design an efficient table relating a tree structure.Huh?
Tree structures are best handled by relational databases, as it is far faster then recursion.
Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.Then design queries to answer questions such as:* Find the nodes in the subtree under B.SELECT * FROM rows WHERE left &gt; [left hand value of B] AND right * Find all ancesters of GSELECT * FROM rows WHERE left  [right hand value of G]* Find the nearest common ancestor of D and HSELECT * FROM rows WHERE left  [highest right hand value from D,H] ORDER BY right LIMIT 1Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.Are you saying trees are easy or hard?
And for more complex systems, that is what JOINs are for.
SQL is by far the most powerful way and often the fastest way to manipulate data that I know of.
The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569381</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246613880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Care to show queries for<br>- inserting nodes<br>- deleting nodes<br>- moving nodes around ?<br>Preordered tree traversal algorithms have tradeoffs, too</p></htmltext>
<tokenext>Care to show queries for- inserting nodes- deleting nodes- moving nodes around ? Preordered tree traversal algorithms have tradeoffs , too</tokentext>
<sentencetext>Care to show queries for- inserting nodes- deleting nodes- moving nodes around ?Preordered tree traversal algorithms have tradeoffs, too</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571663</id>
	<title>Re:A time and place for everything</title>
	<author>Anonymous</author>
	<datestamp>1246635960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>isn't this the technique where you have to lock and update the whole table on insert?</p></htmltext>
<tokenext>is n't this the technique where you have to lock and update the whole table on insert ?</tokentext>
<sentencetext>isn't this the technique where you have to lock and update the whole table on insert?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566245</id>
	<title>IBM's IMS is a Hierarchical Database</title>
	<author>aoheno</author>
	<datestamp>1246538700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>IBM has had a hierarchical database called IMS since 1966 <a href="http://en.wikipedia.org/wiki/IBM\_Information\_Management\_System" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/IBM\_Information\_Management\_System</a> [wikipedia.org] <br> <br>It holds and manipulates data in a hierarchy accessed and manipulated with the DL/I query language <a href="http://en.wikipedia.org/wiki/Data\_Language\_Interface" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Data\_Language\_Interface</a> [wikipedia.org] <br> <br>Now, if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds.<br> <br>Better still, reverse engineer the thing from IBM specs, dropping all the legacy fluff accumulated over 40 years, and call it MyHQL.</htmltext>
<tokenext>IBM has had a hierarchical database called IMS since 1966 http : //en.wikipedia.org/wiki/IBM \ _Information \ _Management \ _System [ wikipedia.org ] It holds and manipulates data in a hierarchy accessed and manipulated with the DL/I query language http : //en.wikipedia.org/wiki/Data \ _Language \ _Interface [ wikipedia.org ] Now , if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds .
Better still , reverse engineer the thing from IBM specs , dropping all the legacy fluff accumulated over 40 years , and call it MyHQL .</tokentext>
<sentencetext>IBM has had a hierarchical database called IMS since 1966 http://en.wikipedia.org/wiki/IBM\_Information\_Management\_System [wikipedia.org]  It holds and manipulates data in a hierarchy accessed and manipulated with the DL/I query language http://en.wikipedia.org/wiki/Data\_Language\_Interface [wikipedia.org]  Now, if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds.
Better still, reverse engineer the thing from IBM specs, dropping all the legacy fluff accumulated over 40 years, and call it MyHQL.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28575737</id>
	<title>Re:Quit Whining</title>
	<author>Anonymous</author>
	<datestamp>1246620600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The on disk representation is fairly independent of the query/update language.  SQL could very easily be implemented on top of tables living in text files.  For querying only the hunting could be pretty easy to do with already existing Unix test processing tools, so an SQL query could be turned into a BASH script using things like sed, sort, and cut.</p></htmltext>
<tokenext>The on disk representation is fairly independent of the query/update language .
SQL could very easily be implemented on top of tables living in text files .
For querying only the hunting could be pretty easy to do with already existing Unix test processing tools , so an SQL query could be turned into a BASH script using things like sed , sort , and cut .</tokentext>
<sentencetext>The on disk representation is fairly independent of the query/update language.
SQL could very easily be implemented on top of tables living in text files.
For querying only the hunting could be pretty easy to do with already existing Unix test processing tools, so an SQL query could be turned into a BASH script using things like sed, sort, and cut.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565389</id>
	<title>What's the benefit exactly?</title>
	<author>SendBot</author>
	<datestamp>1246533840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>I'm not seeing anything that offers a real advantage over using advanced features like one finds in postgres combined with memcached. Some of my program likes to think of its data as a structured object while other parts like seeing that data as rows in a table (they even link up to other tables through foreign keys!).</p></htmltext>
<tokenext>I 'm not seeing anything that offers a real advantage over using advanced features like one finds in postgres combined with memcached .
Some of my program likes to think of its data as a structured object while other parts like seeing that data as rows in a table ( they even link up to other tables through foreign keys !
) .</tokentext>
<sentencetext>I'm not seeing anything that offers a real advantage over using advanced features like one finds in postgres combined with memcached.
Some of my program likes to think of its data as a structured object while other parts like seeing that data as rows in a table (they even link up to other tables through foreign keys!
).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568357</id>
	<title>Seriously misguided</title>
	<author>Stu Charlton</author>
	<datestamp>1246555980000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Trash SQL in favour of coding all your data access needs.   Welcome back to 1973, guys.</p><p>It's <a href="http://en.wikipedia.org/wiki/Teradata" title="wikipedia.org">not like</a> [wikipedia.org] we could do parallel SQL in the 1980's.    Or that you can't do parallel SQL <a href="http://www.vertica.com/" title="vertica.com">in a compute cloud</a> [vertica.com] today.</p><p>No, It basically seems like they don't want to pay software vendors any money for database technology.  That's mostly what the arguments boil down to.   Oracle RAC is very scalable, arguably easier to do at massive scale than MySQL - but you have to pay Oracle money.   For an Internet startup, I can understand why you'd take your chances with "roll your own".  For an enterprise... I think not.</p></htmltext>
<tokenext>Trash SQL in favour of coding all your data access needs .
Welcome back to 1973 , guys.It 's not like [ wikipedia.org ] we could do parallel SQL in the 1980 's .
Or that you ca n't do parallel SQL in a compute cloud [ vertica.com ] today.No , It basically seems like they do n't want to pay software vendors any money for database technology .
That 's mostly what the arguments boil down to .
Oracle RAC is very scalable , arguably easier to do at massive scale than MySQL - but you have to pay Oracle money .
For an Internet startup , I can understand why you 'd take your chances with " roll your own " .
For an enterprise... I think not .</tokentext>
<sentencetext>Trash SQL in favour of coding all your data access needs.
Welcome back to 1973, guys.It's not like [wikipedia.org] we could do parallel SQL in the 1980's.
Or that you can't do parallel SQL in a compute cloud [vertica.com] today.No, It basically seems like they don't want to pay software vendors any money for database technology.
That's mostly what the arguments boil down to.
Oracle RAC is very scalable, arguably easier to do at massive scale than MySQL - but you have to pay Oracle money.
For an Internet startup, I can understand why you'd take your chances with "roll your own".
For an enterprise... I think not.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565865</id>
	<title>Data out-lives applications</title>
	<author>4to6Offshore</author>
	<datestamp>1246536540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>First: my mantra: Data belongs to the organization, not the application... if the app fails and data is accessible then we all go on - if the data fails or is locked away - what was the point of the app again?</p><p>In a SQL database then data is understood by the organisation, DBAs and data architects. If left to app developers taking an app-centric approach to data... I get nervous quickly.</p><p>So long as the data is just as definable and accessible as current SQL databases then all good - give me an app with some odd-ball storage then it is bye-bye.</p></htmltext>
<tokenext>First : my mantra : Data belongs to the organization , not the application... if the app fails and data is accessible then we all go on - if the data fails or is locked away - what was the point of the app again ? In a SQL database then data is understood by the organisation , DBAs and data architects .
If left to app developers taking an app-centric approach to data... I get nervous quickly.So long as the data is just as definable and accessible as current SQL databases then all good - give me an app with some odd-ball storage then it is bye-bye .</tokentext>
<sentencetext>First: my mantra: Data belongs to the organization, not the application... if the app fails and data is accessible then we all go on - if the data fails or is locked away - what was the point of the app again?In a SQL database then data is understood by the organisation, DBAs and data architects.
If left to app developers taking an app-centric approach to data... I get nervous quickly.So long as the data is just as definable and accessible as current SQL databases then all good - give me an app with some odd-ball storage then it is bye-bye.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565627</id>
	<title>SQL is not a database</title>
	<author>Anonymous</author>
	<datestamp>1246535220000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>SQL is not a database, it is a standard interface to a feature set commonly associated with relational models.  Before everyone standardized on SQL, there were other relational query languages. The "No" part of "NoSQL" refers to the fact that some basic elements of relational implementations cannot be usefully expressed using a much simpler distributed hash table model.</p><p>All the "NoSQL" does is eliminate all the parts of traditional relational databases that do no scale -- discarding the bottleneck rather than fixing it. These are things like joins and external indexing. Unfortunately, discarding those things means you discard a lot of very important functionality as a practical matter, notably the ability to do fast, complex analytics. Adopting the NoSQL architecture runs contrary to the trend toward more real-time, contextual analytical processing.  There are a great many analytical applications that are not amenable to batch-mode pattern-matching, and the NoSQL model is a lot less applicable than I think some people want to acknowledge.  In its domain, it is a great tool but it has many, many prohibitive limits. We are essentially trading power for scale.</p><p>That said, do not take this as an endorsement of traditional SQL relational databases either, as they have a number of serious limitations themselves.  As just mentioned, a number of the core analytical operations those models support are based on algorithms that scale poorly.  The SQL language itself has mediocre support for many abstract data types (e.g. spatial) and data models (e.g. graph), which in part reflects the inadequacies of the assumed underlying database algorithms (e.g. B-trees) that are implicit in SQL. The inability to efficiently do event-driven/real-time applications is also more a reflection of the access methods used in databases than any intrinsic weakness in SQL; SQL may be clunky for that purpose, but that is not the real limiter.</p><p>A truly revolutionary deviation from SQL would usefully implement a superset of the features SQL supports, not take them away.  Of course, we would need access methods more capable than hash tables and B-trees to useful implement those features, which is a lot more work than discarding features that scale poorly.  NoSQL is a stopgap technical measure for that small subset of applications where the serious tradeoffs are acceptable.</p></htmltext>
<tokenext>SQL is not a database , it is a standard interface to a feature set commonly associated with relational models .
Before everyone standardized on SQL , there were other relational query languages .
The " No " part of " NoSQL " refers to the fact that some basic elements of relational implementations can not be usefully expressed using a much simpler distributed hash table model.All the " NoSQL " does is eliminate all the parts of traditional relational databases that do no scale -- discarding the bottleneck rather than fixing it .
These are things like joins and external indexing .
Unfortunately , discarding those things means you discard a lot of very important functionality as a practical matter , notably the ability to do fast , complex analytics .
Adopting the NoSQL architecture runs contrary to the trend toward more real-time , contextual analytical processing .
There are a great many analytical applications that are not amenable to batch-mode pattern-matching , and the NoSQL model is a lot less applicable than I think some people want to acknowledge .
In its domain , it is a great tool but it has many , many prohibitive limits .
We are essentially trading power for scale.That said , do not take this as an endorsement of traditional SQL relational databases either , as they have a number of serious limitations themselves .
As just mentioned , a number of the core analytical operations those models support are based on algorithms that scale poorly .
The SQL language itself has mediocre support for many abstract data types ( e.g .
spatial ) and data models ( e.g .
graph ) , which in part reflects the inadequacies of the assumed underlying database algorithms ( e.g .
B-trees ) that are implicit in SQL .
The inability to efficiently do event-driven/real-time applications is also more a reflection of the access methods used in databases than any intrinsic weakness in SQL ; SQL may be clunky for that purpose , but that is not the real limiter.A truly revolutionary deviation from SQL would usefully implement a superset of the features SQL supports , not take them away .
Of course , we would need access methods more capable than hash tables and B-trees to useful implement those features , which is a lot more work than discarding features that scale poorly .
NoSQL is a stopgap technical measure for that small subset of applications where the serious tradeoffs are acceptable .</tokentext>
<sentencetext>SQL is not a database, it is a standard interface to a feature set commonly associated with relational models.
Before everyone standardized on SQL, there were other relational query languages.
The "No" part of "NoSQL" refers to the fact that some basic elements of relational implementations cannot be usefully expressed using a much simpler distributed hash table model.All the "NoSQL" does is eliminate all the parts of traditional relational databases that do no scale -- discarding the bottleneck rather than fixing it.
These are things like joins and external indexing.
Unfortunately, discarding those things means you discard a lot of very important functionality as a practical matter, notably the ability to do fast, complex analytics.
Adopting the NoSQL architecture runs contrary to the trend toward more real-time, contextual analytical processing.
There are a great many analytical applications that are not amenable to batch-mode pattern-matching, and the NoSQL model is a lot less applicable than I think some people want to acknowledge.
In its domain, it is a great tool but it has many, many prohibitive limits.
We are essentially trading power for scale.That said, do not take this as an endorsement of traditional SQL relational databases either, as they have a number of serious limitations themselves.
As just mentioned, a number of the core analytical operations those models support are based on algorithms that scale poorly.
The SQL language itself has mediocre support for many abstract data types (e.g.
spatial) and data models (e.g.
graph), which in part reflects the inadequacies of the assumed underlying database algorithms (e.g.
B-trees) that are implicit in SQL.
The inability to efficiently do event-driven/real-time applications is also more a reflection of the access methods used in databases than any intrinsic weakness in SQL; SQL may be clunky for that purpose, but that is not the real limiter.A truly revolutionary deviation from SQL would usefully implement a superset of the features SQL supports, not take them away.
Of course, we would need access methods more capable than hash tables and B-trees to useful implement those features, which is a lot more work than discarding features that scale poorly.
NoSQL is a stopgap technical measure for that small subset of applications where the serious tradeoffs are acceptable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565227</id>
	<title>SQL....</title>
	<author>Darkness404</author>
	<datestamp>1246532820000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext>SQL has some great uses that its meant for. However, like all OSS tools it can get to where it is used enough for a certain purpose people will try to reuse it to varying success. SQL is great for financial data, however for some of the places it is in, SQL just doesn't do the job well.</htmltext>
<tokenext>SQL has some great uses that its meant for .
However , like all OSS tools it can get to where it is used enough for a certain purpose people will try to reuse it to varying success .
SQL is great for financial data , however for some of the places it is in , SQL just does n't do the job well .</tokentext>
<sentencetext>SQL has some great uses that its meant for.
However, like all OSS tools it can get to where it is used enough for a certain purpose people will try to reuse it to varying success.
SQL is great for financial data, however for some of the places it is in, SQL just doesn't do the job well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570315</id>
	<title>The End Of ...</title>
	<author>jandersen</author>
	<datestamp>1246626780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How many times have we now had somebody announcing "the end of" something? COBOL, FORTRAN, C, mainframes, UNIX - and now SQL. All these things are still around because they serve a useful purpose. It is well possible that this "No-SQL" concept can serve a purpose other than hype, but that largely remains to be seen.</p><p>The big, fundamental advantage of SQL databases, as far as I can see, is not that they are transactional or scalable or fast, but that you can organise your data in a way that fits fairly naturally with your data, and then you can analyse things in ways that you hadn't thought of when you designed the database using the select statement, even if it isn't always the most efficient of tasks. This is one thing that is hard to build in to hierarchical or networked databases, and of course even more so in simple, indexed files. And that is why RDBMSes are going to be the most important kind of databases for a long time yet.</p><p>That is not to say that simpler mechanisms don't have their place; few things beat a simple ISAM file when it comes to whipping up a program that can quickly look up and organise a simple dataset.</p></htmltext>
<tokenext>How many times have we now had somebody announcing " the end of " something ?
COBOL , FORTRAN , C , mainframes , UNIX - and now SQL .
All these things are still around because they serve a useful purpose .
It is well possible that this " No-SQL " concept can serve a purpose other than hype , but that largely remains to be seen.The big , fundamental advantage of SQL databases , as far as I can see , is not that they are transactional or scalable or fast , but that you can organise your data in a way that fits fairly naturally with your data , and then you can analyse things in ways that you had n't thought of when you designed the database using the select statement , even if it is n't always the most efficient of tasks .
This is one thing that is hard to build in to hierarchical or networked databases , and of course even more so in simple , indexed files .
And that is why RDBMSes are going to be the most important kind of databases for a long time yet.That is not to say that simpler mechanisms do n't have their place ; few things beat a simple ISAM file when it comes to whipping up a program that can quickly look up and organise a simple dataset .</tokentext>
<sentencetext>How many times have we now had somebody announcing "the end of" something?
COBOL, FORTRAN, C, mainframes, UNIX - and now SQL.
All these things are still around because they serve a useful purpose.
It is well possible that this "No-SQL" concept can serve a purpose other than hype, but that largely remains to be seen.The big, fundamental advantage of SQL databases, as far as I can see, is not that they are transactional or scalable or fast, but that you can organise your data in a way that fits fairly naturally with your data, and then you can analyse things in ways that you hadn't thought of when you designed the database using the select statement, even if it isn't always the most efficient of tasks.
This is one thing that is hard to build in to hierarchical or networked databases, and of course even more so in simple, indexed files.
And that is why RDBMSes are going to be the most important kind of databases for a long time yet.That is not to say that simpler mechanisms don't have their place; few things beat a simple ISAM file when it comes to whipping up a program that can quickly look up and organise a simple dataset.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481</id>
	<title>Re:A time and place for everything</title>
	<author>TheNarrator</author>
	<datestamp>1246547580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>I think the main problem that the web 2.0 dynamic language crowd has with RDBMs is that:
<ul>
<li>1. Relational data is strongly typed.  You cannot easily add new fields to a table or store arbitrary types in a column and expect acceptable performance.</li><li>2. Migrating large amounts of relational data to a new structure takes a very very long time.  Constant refactoring of data models is to be avoided.  You have to get it right the first time or at least very early in the development cycle to avoid major headaches...</li><li>3. Databases are hard to mock in a testing context.  Automated tests can be significantly slowed down with even a test database..</li><li>4. Error in database architecture are very difficult to correct due to 1 and 2, especially when used with a dynamically typed language..</li><li>5. It's difficult to maintain the data integrity that RDBMSs take for granted in highly scalable distributed systems and have acceptable performance.</li></ul><p>
The only real show stopper and a real reason to replace RDBMSs is #5.  All the others can be worked around by just deeper study of data modeling techniques. Data modelling is not something most developers can figure out intuitively.  There is a lot of theory to be learned to do it right and it can very easily be done badly leading to severe performance problems and an unmaintainable application.
<br>
With regards to # 5: I went to a presentation at Javaone where some Ebay engineers explained that they do not use transactions in any of their database operations.  They just leave junk rows around in the db if a transaction half completes and as long as they aren't reachable they don't consider it a big deal.  They have to very carefully organize the order in which they manipulate data to avoid data corruption<nobr> <wbr></nobr>,but that lets them get around # 5,</p></htmltext>
<tokenext>I think the main problem that the web 2.0 dynamic language crowd has with RDBMs is that : 1 .
Relational data is strongly typed .
You can not easily add new fields to a table or store arbitrary types in a column and expect acceptable performance.2 .
Migrating large amounts of relational data to a new structure takes a very very long time .
Constant refactoring of data models is to be avoided .
You have to get it right the first time or at least very early in the development cycle to avoid major headaches...3 .
Databases are hard to mock in a testing context .
Automated tests can be significantly slowed down with even a test database..4 .
Error in database architecture are very difficult to correct due to 1 and 2 , especially when used with a dynamically typed language..5 .
It 's difficult to maintain the data integrity that RDBMSs take for granted in highly scalable distributed systems and have acceptable performance .
The only real show stopper and a real reason to replace RDBMSs is # 5 .
All the others can be worked around by just deeper study of data modeling techniques .
Data modelling is not something most developers can figure out intuitively .
There is a lot of theory to be learned to do it right and it can very easily be done badly leading to severe performance problems and an unmaintainable application .
With regards to # 5 : I went to a presentation at Javaone where some Ebay engineers explained that they do not use transactions in any of their database operations .
They just leave junk rows around in the db if a transaction half completes and as long as they are n't reachable they do n't consider it a big deal .
They have to very carefully organize the order in which they manipulate data to avoid data corruption ,but that lets them get around # 5,</tokentext>
<sentencetext>I think the main problem that the web 2.0 dynamic language crowd has with RDBMs is that:

1.
Relational data is strongly typed.
You cannot easily add new fields to a table or store arbitrary types in a column and expect acceptable performance.2.
Migrating large amounts of relational data to a new structure takes a very very long time.
Constant refactoring of data models is to be avoided.
You have to get it right the first time or at least very early in the development cycle to avoid major headaches...3.
Databases are hard to mock in a testing context.
Automated tests can be significantly slowed down with even a test database..4.
Error in database architecture are very difficult to correct due to 1 and 2, especially when used with a dynamically typed language..5.
It's difficult to maintain the data integrity that RDBMSs take for granted in highly scalable distributed systems and have acceptable performance.
The only real show stopper and a real reason to replace RDBMSs is #5.
All the others can be worked around by just deeper study of data modeling techniques.
Data modelling is not something most developers can figure out intuitively.
There is a lot of theory to be learned to do it right and it can very easily be done badly leading to severe performance problems and an unmaintainable application.
With regards to # 5: I went to a presentation at Javaone where some Ebay engineers explained that they do not use transactions in any of their database operations.
They just leave junk rows around in the db if a transaction half completes and as long as they aren't reachable they don't consider it a big deal.
They have to very carefully organize the order in which they manipulate data to avoid data corruption ,but that lets them get around # 5,</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553</id>
	<title>Re:Quit Whining</title>
	<author>Anonymous</author>
	<datestamp>1246534740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is one of the main objectives of ReiserFS, to make such things easy, a project which unfortunately has run into some difficulty of late.</htmltext>
<tokenext>This is one of the main objectives of ReiserFS , to make such things easy , a project which unfortunately has run into some difficulty of late .</tokentext>
<sentencetext>This is one of the main objectives of ReiserFS, to make such things easy, a project which unfortunately has run into some difficulty of late.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565237</id>
	<title>THE GREAT AMERICAN BUBBLE MACHINE - By MATT TAIBBI</title>
	<author>Anonymous</author>
	<datestamp>1246532880000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>THE GREAT AMERICAN BUBBLE MACHINE - By MATT TAIBBI - Rolling Stone (Current Issue, July (9-23) 2009) - and two other articles by Matt Taibbi.</p><p>"It's a gangster state, running on gangster economics, and even prices can't be trusted anymore; there are hidden taxes in every buck you pay"</p><p>From tech stocks to high gas prices, Goldman Sachs has engineered every major market manipulation since the Great Depression - and they're about to do it again</p><p>The first thing you need to know about Goldman Sachs is that it's everywhere. The world's most powerful investment bank is a great vampire squid wrapped around the face of humanity, relentlessly jamming its blood funnel into anything that smells like money. In fact, the history of the recent financial crisis, which doubles as a history of the rapid decline and fall of the suddenly swindled-dry American empire, reads like a Who's Who of Goldman Sachs graduates.</p><p>By now, most of us know the major players. As George Bush's last Treasury secretary, former Goldman CEO Henry Paulson was the architect of the bailout, a suspiciously self-serving plan to funnel trillions of Your Dollars to a handful of his old friends on Wall Street. Robert Rubin, Bill Clinton's former Treasury secretary, spent 26 years at Goldman before becoming chairman of Citigroup - which in turn got a $300 billion taxpayer bailout from Paulson. There's John Thain, the rear end in a top hat chief of Merrill Lynch who bought an $87,000 area rug for his office as his company was imploding; a former Goldman banker, Thain enjoyed a multibillion-dollar handout from Paulson, who used billions in taxpayer funds to help Bank of America rescue Thain's sorry company. And Robert Steel, the former Goldmanite head of Wachovia, scored himself and his fellow executives $225 million in golden parachute payments as his bank was self-destructing. There's Joshua Bolten, Bush's chief of staff during the bailout, and Mark Patterson, the current Treasury chief of staff, who was a Goldman lobbyist just a year ago, and Ed Liddy, the former Goldman director whom Paulson put in charge of bailed-out insurance giant AIG, which forked over $13 billion to Goldman after Liddy came on board. The heads of the Canadian and Italian national banks are Goldman alums, as is the head of the World Bank, the head of the New York Stock Exchange, the last two heads of the Federal Reserve Bank of New York - which, incidentally, is now in charge of overseeing Goldman - not to mention<nobr> <wbr></nobr>...</p><p>But then, any attempt to construct a narrative around all the former Goldmanites in influential positions quickly becomes an absurd and pointless exercise, like trying to make a list of everything. What you need to know is the big picture: If America is circling the drain, Goldman Sachs has found a way to be that drain - an extremely unfortunate loophole in the system of Western democratic capitalism, which never foresaw that in a society governed passively by free markets and free elections, organized greed always defeats disorganized democracy.</p><p>The bank's unprecedented reach and power have enabled it to turn all of America into a giant pump-and-dump scam, manipulating whole economic sectors for years at a time, moving the dice game as this or that market collapses, and all the time gorging itself on the unseen costs that are breaking families everywhere - high gas prices, rising consumer-credit rates, half-eaten pension funds, mass layoffs, future taxes to pay off bailouts. All that money that you're losing, it's going somewhere, and in both a literal and a figurative sense, Goldman Sachs is where it's going: The bank is a huge, highly sophisticated engine for converting the useful, deployed wealth of society into the least useful, most wasteful and insoluble substance on Earth - pure profit for rich individuals.</p><p>They achieve this using the same playbook over and over again. The formula is relatively simple: Goldman positions itself in the middle of a speculative bubble, selling investments they know are crap. Then they</p></htmltext>
<tokenext>THE GREAT AMERICAN BUBBLE MACHINE - By MATT TAIBBI - Rolling Stone ( Current Issue , July ( 9-23 ) 2009 ) - and two other articles by Matt Taibbi .
" It 's a gangster state , running on gangster economics , and even prices ca n't be trusted anymore ; there are hidden taxes in every buck you pay " From tech stocks to high gas prices , Goldman Sachs has engineered every major market manipulation since the Great Depression - and they 're about to do it againThe first thing you need to know about Goldman Sachs is that it 's everywhere .
The world 's most powerful investment bank is a great vampire squid wrapped around the face of humanity , relentlessly jamming its blood funnel into anything that smells like money .
In fact , the history of the recent financial crisis , which doubles as a history of the rapid decline and fall of the suddenly swindled-dry American empire , reads like a Who 's Who of Goldman Sachs graduates.By now , most of us know the major players .
As George Bush 's last Treasury secretary , former Goldman CEO Henry Paulson was the architect of the bailout , a suspiciously self-serving plan to funnel trillions of Your Dollars to a handful of his old friends on Wall Street .
Robert Rubin , Bill Clinton 's former Treasury secretary , spent 26 years at Goldman before becoming chairman of Citigroup - which in turn got a $ 300 billion taxpayer bailout from Paulson .
There 's John Thain , the rear end in a top hat chief of Merrill Lynch who bought an $ 87,000 area rug for his office as his company was imploding ; a former Goldman banker , Thain enjoyed a multibillion-dollar handout from Paulson , who used billions in taxpayer funds to help Bank of America rescue Thain 's sorry company .
And Robert Steel , the former Goldmanite head of Wachovia , scored himself and his fellow executives $ 225 million in golden parachute payments as his bank was self-destructing .
There 's Joshua Bolten , Bush 's chief of staff during the bailout , and Mark Patterson , the current Treasury chief of staff , who was a Goldman lobbyist just a year ago , and Ed Liddy , the former Goldman director whom Paulson put in charge of bailed-out insurance giant AIG , which forked over $ 13 billion to Goldman after Liddy came on board .
The heads of the Canadian and Italian national banks are Goldman alums , as is the head of the World Bank , the head of the New York Stock Exchange , the last two heads of the Federal Reserve Bank of New York - which , incidentally , is now in charge of overseeing Goldman - not to mention ...But then , any attempt to construct a narrative around all the former Goldmanites in influential positions quickly becomes an absurd and pointless exercise , like trying to make a list of everything .
What you need to know is the big picture : If America is circling the drain , Goldman Sachs has found a way to be that drain - an extremely unfortunate loophole in the system of Western democratic capitalism , which never foresaw that in a society governed passively by free markets and free elections , organized greed always defeats disorganized democracy.The bank 's unprecedented reach and power have enabled it to turn all of America into a giant pump-and-dump scam , manipulating whole economic sectors for years at a time , moving the dice game as this or that market collapses , and all the time gorging itself on the unseen costs that are breaking families everywhere - high gas prices , rising consumer-credit rates , half-eaten pension funds , mass layoffs , future taxes to pay off bailouts .
All that money that you 're losing , it 's going somewhere , and in both a literal and a figurative sense , Goldman Sachs is where it 's going : The bank is a huge , highly sophisticated engine for converting the useful , deployed wealth of society into the least useful , most wasteful and insoluble substance on Earth - pure profit for rich individuals.They achieve this using the same playbook over and over again .
The formula is relatively simple : Goldman positions itself in the middle of a speculative bubble , selling investments they know are crap .
Then they</tokentext>
<sentencetext>THE GREAT AMERICAN BUBBLE MACHINE - By MATT TAIBBI - Rolling Stone (Current Issue, July (9-23) 2009) - and two other articles by Matt Taibbi.
"It's a gangster state, running on gangster economics, and even prices can't be trusted anymore; there are hidden taxes in every buck you pay"From tech stocks to high gas prices, Goldman Sachs has engineered every major market manipulation since the Great Depression - and they're about to do it againThe first thing you need to know about Goldman Sachs is that it's everywhere.
The world's most powerful investment bank is a great vampire squid wrapped around the face of humanity, relentlessly jamming its blood funnel into anything that smells like money.
In fact, the history of the recent financial crisis, which doubles as a history of the rapid decline and fall of the suddenly swindled-dry American empire, reads like a Who's Who of Goldman Sachs graduates.By now, most of us know the major players.
As George Bush's last Treasury secretary, former Goldman CEO Henry Paulson was the architect of the bailout, a suspiciously self-serving plan to funnel trillions of Your Dollars to a handful of his old friends on Wall Street.
Robert Rubin, Bill Clinton's former Treasury secretary, spent 26 years at Goldman before becoming chairman of Citigroup - which in turn got a $300 billion taxpayer bailout from Paulson.
There's John Thain, the rear end in a top hat chief of Merrill Lynch who bought an $87,000 area rug for his office as his company was imploding; a former Goldman banker, Thain enjoyed a multibillion-dollar handout from Paulson, who used billions in taxpayer funds to help Bank of America rescue Thain's sorry company.
And Robert Steel, the former Goldmanite head of Wachovia, scored himself and his fellow executives $225 million in golden parachute payments as his bank was self-destructing.
There's Joshua Bolten, Bush's chief of staff during the bailout, and Mark Patterson, the current Treasury chief of staff, who was a Goldman lobbyist just a year ago, and Ed Liddy, the former Goldman director whom Paulson put in charge of bailed-out insurance giant AIG, which forked over $13 billion to Goldman after Liddy came on board.
The heads of the Canadian and Italian national banks are Goldman alums, as is the head of the World Bank, the head of the New York Stock Exchange, the last two heads of the Federal Reserve Bank of New York - which, incidentally, is now in charge of overseeing Goldman - not to mention ...But then, any attempt to construct a narrative around all the former Goldmanites in influential positions quickly becomes an absurd and pointless exercise, like trying to make a list of everything.
What you need to know is the big picture: If America is circling the drain, Goldman Sachs has found a way to be that drain - an extremely unfortunate loophole in the system of Western democratic capitalism, which never foresaw that in a society governed passively by free markets and free elections, organized greed always defeats disorganized democracy.The bank's unprecedented reach and power have enabled it to turn all of America into a giant pump-and-dump scam, manipulating whole economic sectors for years at a time, moving the dice game as this or that market collapses, and all the time gorging itself on the unseen costs that are breaking families everywhere - high gas prices, rising consumer-credit rates, half-eaten pension funds, mass layoffs, future taxes to pay off bailouts.
All that money that you're losing, it's going somewhere, and in both a literal and a figurative sense, Goldman Sachs is where it's going: The bank is a huge, highly sophisticated engine for converting the useful, deployed wealth of society into the least useful, most wasteful and insoluble substance on Earth - pure profit for rich individuals.They achieve this using the same playbook over and over again.
The formula is relatively simple: Goldman positions itself in the middle of a speculative bubble, selling investments they know are crap.
Then they</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570249</id>
	<title>Absolute BS!</title>
	<author>Anonymous</author>
	<datestamp>1246625940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>As a DBA for a major well know RDBMS product, we get this crap every few years, "A new paradigm!". Yeah well the first time you load you wonderful no optimised SQL into any puckka RDBMS system, it will balk and like a bunch pre-schoolers all go crying to thr DBA that you app won't work any more. It worked fine with 2 test users, but now with 2,000 it balks and crashes! Duh! Wonder why? 'Cos you're a plank who believes all the RAD product BS!</htmltext>
<tokenext>As a DBA for a major well know RDBMS product , we get this crap every few years , " A new paradigm ! " .
Yeah well the first time you load you wonderful no optimised SQL into any puckka RDBMS system , it will balk and like a bunch pre-schoolers all go crying to thr DBA that you app wo n't work any more .
It worked fine with 2 test users , but now with 2,000 it balks and crashes !
Duh ! Wonder why ?
'Cos you 're a plank who believes all the RAD product BS !</tokentext>
<sentencetext>As a DBA for a major well know RDBMS product, we get this crap every few years, "A new paradigm!".
Yeah well the first time you load you wonderful no optimised SQL into any puckka RDBMS system, it will balk and like a bunch pre-schoolers all go crying to thr DBA that you app won't work any more.
It worked fine with 2 test users, but now with 2,000 it balks and crashes!
Duh! Wonder why?
'Cos you're a plank who believes all the RAD product BS!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572337</id>
	<title>Re:Not mutually exclusive</title>
	<author>Anonymous</author>
	<datestamp>1246639740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The only reason SQL won't be around longer than COBOL is that COBOL was created before SQL.</p></htmltext>
<tokenext>The only reason SQL wo n't be around longer than COBOL is that COBOL was created before SQL .</tokentext>
<sentencetext>The only reason SQL won't be around longer than COBOL is that COBOL was created before SQL.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565357</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265</id>
	<title>Re:Quit Whining</title>
	<author>CyberLife</author>
	<datestamp>1246545540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Flat files are a perfectly viable option in some circumstances. Not everything requires data uniformity or the ability to run complex ad-hoc queries, nor does everything need information to be controlled by a separate process running on a different machine. Not every system integrates multiple applications through a shared data-store. The NoSQL crowd isn't arguing that SQL is bad, just overused. There are a great many situations where something like flat files or Berkeley DB is more than sufficient, and yet people still use relational technology. In my experience it's generally because that's all they know. In their mind, if one needs to store data one uses SQL. They don't select the right tool for the job because they honestly don't know there are other tools.</p></htmltext>
<tokenext>Flat files are a perfectly viable option in some circumstances .
Not everything requires data uniformity or the ability to run complex ad-hoc queries , nor does everything need information to be controlled by a separate process running on a different machine .
Not every system integrates multiple applications through a shared data-store .
The NoSQL crowd is n't arguing that SQL is bad , just overused .
There are a great many situations where something like flat files or Berkeley DB is more than sufficient , and yet people still use relational technology .
In my experience it 's generally because that 's all they know .
In their mind , if one needs to store data one uses SQL .
They do n't select the right tool for the job because they honestly do n't know there are other tools .</tokentext>
<sentencetext>Flat files are a perfectly viable option in some circumstances.
Not everything requires data uniformity or the ability to run complex ad-hoc queries, nor does everything need information to be controlled by a separate process running on a different machine.
Not every system integrates multiple applications through a shared data-store.
The NoSQL crowd isn't arguing that SQL is bad, just overused.
There are a great many situations where something like flat files or Berkeley DB is more than sufficient, and yet people still use relational technology.
In my experience it's generally because that's all they know.
In their mind, if one needs to store data one uses SQL.
They don't select the right tool for the job because they honestly don't know there are other tools.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570485</id>
	<title>Re:A time and place for everything</title>
	<author>cyclomedia</author>
	<datestamp>1246628160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
Actually 1 and 2 are pretty big pains in the bottom when all you want is a customer -&gt; order -&gt; products * qty relationship or a news -&gt; items -&gt; attached images relationship. A lot of the time you will never ever in a zillion years need to see the  orderID from code because
all you need to do is some pointer munginh something like:
</p><p>
<tt>
    theCustomer.currentOrder.Items[0].Quantity++;
</tt></p><p>
One of the new-age / agile mantras of code is refactor-as-you-go-(just-make-sure-it-all-compiles-and-runs-too). And #1 and #2 are bitches when you need to change an object's property from a straight yes/no (mapped to a database boolean) to an choice between yes,no,doesn't-know,hasn't-filled-in-form-yet. (not to mention the pains of getting an enum/lookup into and out of a database what with lookup tables and data columns that are just filled with meaningless ids) it'd be nice if from a developers point of view refactoring the class also refactored the underlying data storage. This would be find for 95\% of database driven apps and websites, with the RDBMS expert only needed to be called in when you need to archive, mirror, distribute and stabilise the backend because your customers per day went above eight.
</p></htmltext>
<tokenext>Actually 1 and 2 are pretty big pains in the bottom when all you want is a customer - &gt; order - &gt; products * qty relationship or a news - &gt; items - &gt; attached images relationship .
A lot of the time you will never ever in a zillion years need to see the orderID from code because all you need to do is some pointer munginh something like : theCustomer.currentOrder.Items [ 0 ] .Quantity + + ; One of the new-age / agile mantras of code is refactor-as-you-go- ( just-make-sure-it-all-compiles-and-runs-too ) .
And # 1 and # 2 are bitches when you need to change an object 's property from a straight yes/no ( mapped to a database boolean ) to an choice between yes,no,does n't-know,has n't-filled-in-form-yet .
( not to mention the pains of getting an enum/lookup into and out of a database what with lookup tables and data columns that are just filled with meaningless ids ) it 'd be nice if from a developers point of view refactoring the class also refactored the underlying data storage .
This would be find for 95 \ % of database driven apps and websites , with the RDBMS expert only needed to be called in when you need to archive , mirror , distribute and stabilise the backend because your customers per day went above eight .</tokentext>
<sentencetext>
Actually 1 and 2 are pretty big pains in the bottom when all you want is a customer -&gt; order -&gt; products * qty relationship or a news -&gt; items -&gt; attached images relationship.
A lot of the time you will never ever in a zillion years need to see the  orderID from code because
all you need to do is some pointer munginh something like:


    theCustomer.currentOrder.Items[0].Quantity++;

One of the new-age / agile mantras of code is refactor-as-you-go-(just-make-sure-it-all-compiles-and-runs-too).
And #1 and #2 are bitches when you need to change an object's property from a straight yes/no (mapped to a database boolean) to an choice between yes,no,doesn't-know,hasn't-filled-in-form-yet.
(not to mention the pains of getting an enum/lookup into and out of a database what with lookup tables and data columns that are just filled with meaningless ids) it'd be nice if from a developers point of view refactoring the class also refactored the underlying data storage.
This would be find for 95\% of database driven apps and websites, with the RDBMS expert only needed to be called in when you need to archive, mirror, distribute and stabilise the backend because your customers per day went above eight.
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574183</id>
	<title>Re:Flat Earth</title>
	<author>jadavis</author>
	<datestamp>1246652040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>First, you have to strike out toward new things if you want to progress the world.</i></p><p>In this case, people are striking out towards things even older than SQL: key-value and graph database systems. Just because it has a new name doesn't make it new.</p></htmltext>
<tokenext>First , you have to strike out toward new things if you want to progress the world.In this case , people are striking out towards things even older than SQL : key-value and graph database systems .
Just because it has a new name does n't make it new .</tokentext>
<sentencetext>First, you have to strike out toward new things if you want to progress the world.In this case, people are striking out towards things even older than SQL: key-value and graph database systems.
Just because it has a new name doesn't make it new.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566273</id>
	<title>Relational good, SQL not so</title>
	<author>Anonymous</author>
	<datestamp>1246538820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Relational database have plenty of good uses.  They are not the universal solution to data storage, but there are plenty of cases where they are the best case.  I would certainly not use a relational database just to store user passwords.  Something like Berkeley DB would be good.  I have used raw files individually (one file per user named by username) with good success (the underlying filesystem was Reiserfs with tail packing enabled).  But even where a relation database is called for (a CRM system, for example), I find that SQL is always a hindrance.  I'd rather just get the data across a simple protocol (which can be wrapped in a simple API binding for the language in use).</p></htmltext>
<tokenext>Relational database have plenty of good uses .
They are not the universal solution to data storage , but there are plenty of cases where they are the best case .
I would certainly not use a relational database just to store user passwords .
Something like Berkeley DB would be good .
I have used raw files individually ( one file per user named by username ) with good success ( the underlying filesystem was Reiserfs with tail packing enabled ) .
But even where a relation database is called for ( a CRM system , for example ) , I find that SQL is always a hindrance .
I 'd rather just get the data across a simple protocol ( which can be wrapped in a simple API binding for the language in use ) .</tokentext>
<sentencetext>Relational database have plenty of good uses.
They are not the universal solution to data storage, but there are plenty of cases where they are the best case.
I would certainly not use a relational database just to store user passwords.
Something like Berkeley DB would be good.
I have used raw files individually (one file per user named by username) with good success (the underlying filesystem was Reiserfs with tail packing enabled).
But even where a relation database is called for (a CRM system, for example), I find that SQL is always a hindrance.
I'd rather just get the data across a simple protocol (which can be wrapped in a simple API binding for the language in use).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565485</id>
	<title>What else is there to use besides SQL</title>
	<author>Orion Blastar</author>
	<datestamp>1246534380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>go back to flat files aka DAT files.</p><p>Use the old DBase III standard DBF files?</p><p>Use the old Lotus 123 WK1 files?</p><p>Use MS-Office MS-Access MS-Excel etc files?</p><p>Use comma separated values files?</p><p>SQL set a standard for relational databases, a structured query language that almost any database can use and then build extensions to it.</p><p>Will the Post-SQL age begin, and will it be object oriented and a fifth generation language?</p></htmltext>
<tokenext>go back to flat files aka DAT files.Use the old DBase III standard DBF files ? Use the old Lotus 123 WK1 files ? Use MS-Office MS-Access MS-Excel etc files ? Use comma separated values files ? SQL set a standard for relational databases , a structured query language that almost any database can use and then build extensions to it.Will the Post-SQL age begin , and will it be object oriented and a fifth generation language ?</tokentext>
<sentencetext>go back to flat files aka DAT files.Use the old DBase III standard DBF files?Use the old Lotus 123 WK1 files?Use MS-Office MS-Access MS-Excel etc files?Use comma separated values files?SQL set a standard for relational databases, a structured query language that almost any database can use and then build extensions to it.Will the Post-SQL age begin, and will it be object oriented and a fifth generation language?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043</id>
	<title>Re:A time and place for everything</title>
	<author>E IS mC(Square)</author>
	<datestamp>1246537500000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext>&gt;&gt; Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.
<br> <br>
Sorry, that's not true. Have you tried analytical functions? You would be amazed how complex scenarios can be handled easily with them. And they are part of ANSI SQL standards. And db providers (Oracle etc) have taken the concept and improved a lot on it.
<br> <br>
I think the anti-sql 'movement' has more to do with new (internet era) languages and their developers than so called 'lack' of features. In my limited experience, I have observed people coming from C (and such) background have no problem with sql, while java developers (and this is probably true for most developers working on web-based applications) are the worst kind when it comes to understanding even basics of sql. All they want is their objects.
<br> <br>
I strongly believe that a competent programmer designing/developing system which includes data and data-storage should at least know normalization, indexes, and what does it mean by 3NF. Programming language is one thing, database is another, and knowledge of both is required to build a decent system.</htmltext>
<tokenext>&gt; &gt; Trees is a wellknown problem of SQL , but the fact is that SQL ca n't handle most datastructures and complex relations , only very simple one dimensional ones .
Sorry , that 's not true .
Have you tried analytical functions ?
You would be amazed how complex scenarios can be handled easily with them .
And they are part of ANSI SQL standards .
And db providers ( Oracle etc ) have taken the concept and improved a lot on it .
I think the anti-sql 'movement ' has more to do with new ( internet era ) languages and their developers than so called 'lack ' of features .
In my limited experience , I have observed people coming from C ( and such ) background have no problem with sql , while java developers ( and this is probably true for most developers working on web-based applications ) are the worst kind when it comes to understanding even basics of sql .
All they want is their objects .
I strongly believe that a competent programmer designing/developing system which includes data and data-storage should at least know normalization , indexes , and what does it mean by 3NF .
Programming language is one thing , database is another , and knowledge of both is required to build a decent system .</tokentext>
<sentencetext>&gt;&gt; Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.
Sorry, that's not true.
Have you tried analytical functions?
You would be amazed how complex scenarios can be handled easily with them.
And they are part of ANSI SQL standards.
And db providers (Oracle etc) have taken the concept and improved a lot on it.
I think the anti-sql 'movement' has more to do with new (internet era) languages and their developers than so called 'lack' of features.
In my limited experience, I have observed people coming from C (and such) background have no problem with sql, while java developers (and this is probably true for most developers working on web-based applications) are the worst kind when it comes to understanding even basics of sql.
All they want is their objects.
I strongly believe that a competent programmer designing/developing system which includes data and data-storage should at least know normalization, indexes, and what does it mean by 3NF.
Programming language is one thing, database is another, and knowledge of both is required to build a decent system.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569039</id>
	<title>I see SQL as more of a "protocol"</title>
	<author>TheLink</author>
	<datestamp>1246652040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>You can use SQL with flat files.<br><br>SQL is going to be around for a long time, because it's useful as an "API" - as a protocol or layer of abstraction.<br><br>Programmers can write all sorts of programs in all sorts of programming languages and then use SQL to talk to the DB. If the DB changes a bit, they can often use the same SQL or modify it slightly.<br><br>You often see lots of grumbling and cursing in various companies because people actually end up doing that and companies end up with lots of stuff hooked to the DB - MS Access, perl, python, ruby, java, radius servers, openvpn, accounting and finance stuff...<br><br>They grumble, but the fact is the database is being used. The data has become more useful.<br><br>If you have your database locked up behind some new fangled protocol that only 20 people in the world know, it's not going to be as easy to do that - and often each bunch will start creating their own databases and you end up with a different mess, and a mess that's not as useful.<br><br>Having everyone use SQL to talk to the DB is not actually a bug it's a feature.<br><br>One man's impedance mismatch is another man's layer of abstraction.</htmltext>
<tokenext>You can use SQL with flat files.SQL is going to be around for a long time , because it 's useful as an " API " - as a protocol or layer of abstraction.Programmers can write all sorts of programs in all sorts of programming languages and then use SQL to talk to the DB .
If the DB changes a bit , they can often use the same SQL or modify it slightly.You often see lots of grumbling and cursing in various companies because people actually end up doing that and companies end up with lots of stuff hooked to the DB - MS Access , perl , python , ruby , java , radius servers , openvpn , accounting and finance stuff...They grumble , but the fact is the database is being used .
The data has become more useful.If you have your database locked up behind some new fangled protocol that only 20 people in the world know , it 's not going to be as easy to do that - and often each bunch will start creating their own databases and you end up with a different mess , and a mess that 's not as useful.Having everyone use SQL to talk to the DB is not actually a bug it 's a feature.One man 's impedance mismatch is another man 's layer of abstraction .</tokentext>
<sentencetext>You can use SQL with flat files.SQL is going to be around for a long time, because it's useful as an "API" - as a protocol or layer of abstraction.Programmers can write all sorts of programs in all sorts of programming languages and then use SQL to talk to the DB.
If the DB changes a bit, they can often use the same SQL or modify it slightly.You often see lots of grumbling and cursing in various companies because people actually end up doing that and companies end up with lots of stuff hooked to the DB - MS Access, perl, python, ruby, java, radius servers, openvpn, accounting and finance stuff...They grumble, but the fact is the database is being used.
The data has become more useful.If you have your database locked up behind some new fangled protocol that only 20 people in the world know, it's not going to be as easy to do that - and often each bunch will start creating their own databases and you end up with a different mess, and a mess that's not as useful.Having everyone use SQL to talk to the DB is not actually a bug it's a feature.One man's impedance mismatch is another man's layer of abstraction.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567113</id>
	<title>Re:A time and place for everything</title>
	<author>lumbercartel.ca</author>
	<datestamp>1246544640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't agree either.  JavaScript is a vague language, and partly thanks to the web browser wars.  If JavaScript was actually properly standardized across web browsers, then web developers wouldn't be stuck having to write huge amounts of conditional code just to make it work in Internet Exploder, and then more when doing really complicated stuff.  Take a look at any cross-browser JavaScript menu system that supports Opera, Firefox, Safari, Google Chrome, Internet Explorer, and others, and it's easy to find lots of these conditional statements to work-around various infuriating web browser incompatibilities.</p><p>SQL, on the other hand, doesn't tend to suffer from these problems because the client-side isn't choosing which database engine is being used behind the scenes, so the DBAs and other system administrators can get the consistency they need.  Sure, every database vendor is tweaking the standards (or relying on outdated standards like MySQL has for a long time -- I don't know if they're still locked into the old SQL standard anymore because I use PostgreSQL for all my database needs), but generally most of the more common statements work very similarily, so moving between database engines (and adapting and testing code accordingly) is far easier than making JavaScript work consistently across multiple versions of multiple web browsers.</p></htmltext>
<tokenext>I do n't agree either .
JavaScript is a vague language , and partly thanks to the web browser wars .
If JavaScript was actually properly standardized across web browsers , then web developers would n't be stuck having to write huge amounts of conditional code just to make it work in Internet Exploder , and then more when doing really complicated stuff .
Take a look at any cross-browser JavaScript menu system that supports Opera , Firefox , Safari , Google Chrome , Internet Explorer , and others , and it 's easy to find lots of these conditional statements to work-around various infuriating web browser incompatibilities.SQL , on the other hand , does n't tend to suffer from these problems because the client-side is n't choosing which database engine is being used behind the scenes , so the DBAs and other system administrators can get the consistency they need .
Sure , every database vendor is tweaking the standards ( or relying on outdated standards like MySQL has for a long time -- I do n't know if they 're still locked into the old SQL standard anymore because I use PostgreSQL for all my database needs ) , but generally most of the more common statements work very similarily , so moving between database engines ( and adapting and testing code accordingly ) is far easier than making JavaScript work consistently across multiple versions of multiple web browsers .</tokentext>
<sentencetext>I don't agree either.
JavaScript is a vague language, and partly thanks to the web browser wars.
If JavaScript was actually properly standardized across web browsers, then web developers wouldn't be stuck having to write huge amounts of conditional code just to make it work in Internet Exploder, and then more when doing really complicated stuff.
Take a look at any cross-browser JavaScript menu system that supports Opera, Firefox, Safari, Google Chrome, Internet Explorer, and others, and it's easy to find lots of these conditional statements to work-around various infuriating web browser incompatibilities.SQL, on the other hand, doesn't tend to suffer from these problems because the client-side isn't choosing which database engine is being used behind the scenes, so the DBAs and other system administrators can get the consistency they need.
Sure, every database vendor is tweaking the standards (or relying on outdated standards like MySQL has for a long time -- I don't know if they're still locked into the old SQL standard anymore because I use PostgreSQL for all my database needs), but generally most of the more common statements work very similarily, so moving between database engines (and adapting and testing code accordingly) is far easier than making JavaScript work consistently across multiple versions of multiple web browsers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566297</id>
	<title>Re:Next Up...</title>
	<author>grepya</author>
	<datestamp>1246539000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Great job moderator.  It's an attempt to make a reasonable point with the help of a deliberately over-the-top analogy. You maynot agree with the point I'm trying to make (that much is obvious), or you may not agree with the applicability of my analogy (which, I humbly submit, is pretty close). That doesn't make it trolling.</p></htmltext>
<tokenext>Great job moderator .
It 's an attempt to make a reasonable point with the help of a deliberately over-the-top analogy .
You maynot agree with the point I 'm trying to make ( that much is obvious ) , or you may not agree with the applicability of my analogy ( which , I humbly submit , is pretty close ) .
That does n't make it trolling .</tokentext>
<sentencetext>Great job moderator.
It's an attempt to make a reasonable point with the help of a deliberately over-the-top analogy.
You maynot agree with the point I'm trying to make (that much is obvious), or you may not agree with the applicability of my analogy (which, I humbly submit, is pretty close).
That doesn't make it trolling.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565269</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568051</id>
	<title>Toss the bathwater, not the dBaby</title>
	<author>Tablizer</author>
	<datestamp>1246552920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem with the existing RDBMS is not so much relational nor SQL[1], but the fact that they are not dynamic. Why not allow columns and tables to be created willy-nilly and without (up-front) width limits, like in a dynamic programming language? It would need a more flexible type system, or even do away with internal types and make the operators a bit more type-explicit, like Perl does. <b>We have static/compiled programming languages and dynamic/interpreted programming languages. Why not have a similar choice with RDBMS?</b> Stop cloning Oracle's style of relational so closely.</p><p>[1] There's a few minor tweaks that could be done to SQL to improve some really sore spots, like named temporary query references, a kind of user-defined and/or temporary views. This would reduce run-on sentence queries. There's also graph and tree traversal query needs, but somebody pointed out that these already exist to some extent.</p></htmltext>
<tokenext>The problem with the existing RDBMS is not so much relational nor SQL [ 1 ] , but the fact that they are not dynamic .
Why not allow columns and tables to be created willy-nilly and without ( up-front ) width limits , like in a dynamic programming language ?
It would need a more flexible type system , or even do away with internal types and make the operators a bit more type-explicit , like Perl does .
We have static/compiled programming languages and dynamic/interpreted programming languages .
Why not have a similar choice with RDBMS ?
Stop cloning Oracle 's style of relational so closely .
[ 1 ] There 's a few minor tweaks that could be done to SQL to improve some really sore spots , like named temporary query references , a kind of user-defined and/or temporary views .
This would reduce run-on sentence queries .
There 's also graph and tree traversal query needs , but somebody pointed out that these already exist to some extent .</tokentext>
<sentencetext>The problem with the existing RDBMS is not so much relational nor SQL[1], but the fact that they are not dynamic.
Why not allow columns and tables to be created willy-nilly and without (up-front) width limits, like in a dynamic programming language?
It would need a more flexible type system, or even do away with internal types and make the operators a bit more type-explicit, like Perl does.
We have static/compiled programming languages and dynamic/interpreted programming languages.
Why not have a similar choice with RDBMS?
Stop cloning Oracle's style of relational so closely.
[1] There's a few minor tweaks that could be done to SQL to improve some really sore spots, like named temporary query references, a kind of user-defined and/or temporary views.
This would reduce run-on sentence queries.
There's also graph and tree traversal query needs, but somebody pointed out that these already exist to some extent.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28663115</id>
	<title>Re:Pros &amp; Cons of non-relational solutions</title>
	<author>Anonymous</author>
	<datestamp>1247306160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>The basic premise is that we need different solutions that: can scale very high for very narrowly scoped reads &amp; writes,  don't need to perform ranged queries / reporting<nobr> <wbr></nobr>/etc, and don't need ACID compliance.   And that may be the case.  Sites like slashdot, facebook, reddit, digg, etc don't need the data quality that ebay needs.</p></div><p>So you're saying those organizations can get by with a "half-ACID" solution?</p></div>
	</htmltext>
<tokenext>The basic premise is that we need different solutions that : can scale very high for very narrowly scoped reads &amp; writes , do n't need to perform ranged queries / reporting /etc , and do n't need ACID compliance .
And that may be the case .
Sites like slashdot , facebook , reddit , digg , etc do n't need the data quality that ebay needs.So you 're saying those organizations can get by with a " half-ACID " solution ?</tokentext>
<sentencetext>The basic premise is that we need different solutions that: can scale very high for very narrowly scoped reads &amp; writes,  don't need to perform ranged queries / reporting /etc, and don't need ACID compliance.
And that may be the case.
Sites like slashdot, facebook, reddit, digg, etc don't need the data quality that ebay needs.So you're saying those organizations can get by with a "half-ACID" solution?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566859</id>
	<title>Re:RDBs are good, but SQL is horrible</title>
	<author>voidphoenix</author>
	<datestamp>1246542720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Inner joins produce intersections of data --  they limit the result set. Outer joins produce Cartesian result sets. That's why they're also referred to as Cartesian joins.</htmltext>
<tokenext>Inner joins produce intersections of data -- they limit the result set .
Outer joins produce Cartesian result sets .
That 's why they 're also referred to as Cartesian joins .</tokentext>
<sentencetext>Inner joins produce intersections of data --  they limit the result set.
Outer joins produce Cartesian result sets.
That's why they're also referred to as Cartesian joins.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568403</id>
	<title>lots of these guys belong to flat earth society</title>
	<author>Dan667</author>
	<datestamp>1246556700000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext>Think of the discussions!</htmltext>
<tokenext>Think of the discussions !</tokentext>
<sentencetext>Think of the discussions!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199</id>
	<title>Flat Earth</title>
	<author>Seumas</author>
	<datestamp>1246532760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>I've seen strong reactions from various camps with regard to concern over saying no to SQL. I'm not sure why people freak out over it. First, you have to strike out toward new things if you want to progress the world. Second, SQL hasn't caused people to stop using spreadsheets or Access databases. Third, there are groups that get together to dispute that the earth is round; insisting that it is flat. Or that gray aliens are visiting earth regularly and probing our anuses.</p><p>Bring on the next fascinating data technology. SQL will continue to have a major place for many years to come, no matter what happens.</p></htmltext>
<tokenext>I 've seen strong reactions from various camps with regard to concern over saying no to SQL .
I 'm not sure why people freak out over it .
First , you have to strike out toward new things if you want to progress the world .
Second , SQL has n't caused people to stop using spreadsheets or Access databases .
Third , there are groups that get together to dispute that the earth is round ; insisting that it is flat .
Or that gray aliens are visiting earth regularly and probing our anuses.Bring on the next fascinating data technology .
SQL will continue to have a major place for many years to come , no matter what happens .</tokentext>
<sentencetext>I've seen strong reactions from various camps with regard to concern over saying no to SQL.
I'm not sure why people freak out over it.
First, you have to strike out toward new things if you want to progress the world.
Second, SQL hasn't caused people to stop using spreadsheets or Access databases.
Third, there are groups that get together to dispute that the earth is round; insisting that it is flat.
Or that gray aliens are visiting earth regularly and probing our anuses.Bring on the next fascinating data technology.
SQL will continue to have a major place for many years to come, no matter what happens.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565265</id>
	<title>RDB</title>
	<author>MichaelSmith</author>
	<datestamp>1246533060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I thought DEC RDB was a pretty good query language. I never got into SQL as a result. I am glad people are thinking about alternatives.</htmltext>
<tokenext>I thought DEC RDB was a pretty good query language .
I never got into SQL as a result .
I am glad people are thinking about alternatives .</tokentext>
<sentencetext>I thought DEC RDB was a pretty good query language.
I never got into SQL as a result.
I am glad people are thinking about alternatives.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569157</id>
	<title>Re:A time and place for everything</title>
	<author>frenchbedroom</author>
	<datestamp>1246653720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I remember using that model in a project about 5 years ago. Great performance when querying. Deleting a node is straightforward, you can leave the child nodes as they are and your queries will still work. But inserting or updating can be expensive operations.</htmltext>
<tokenext>I remember using that model in a project about 5 years ago .
Great performance when querying .
Deleting a node is straightforward , you can leave the child nodes as they are and your queries will still work .
But inserting or updating can be expensive operations .</tokentext>
<sentencetext>I remember using that model in a project about 5 years ago.
Great performance when querying.
Deleting a node is straightforward, you can leave the child nodes as they are and your queries will still work.
But inserting or updating can be expensive operations.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572517</id>
	<title>Re:A time and place for everything</title>
	<author>jadavis</author>
	<datestamp>1246641060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Then design queries to answer questions such as</i></p><p>Those questions can be answered quite easily using either a materialized path representation (using something like <a href="http://www.postgresql.org/docs/8.4/static/ltree.html" title="postgresql.org">ltree</a> [postgresql.org], or <a href="http://www.postgresql.org/docs/8.4/static/sql-select.html#SQL-WITH" title="postgresql.org">WITH<nobr> <wbr></nobr>... RECURSIVE</a> [postgresql.org].</p><p>Materialized path would be an efficient way to answer those questions. However, if you try to use some graph or hierarchical database system, then that will be the only way you can efficiently access your data; with a SQL system, it's easier to allow the user to ask a variety of very different questions without bias toward any one particular type of question.</p><p>Consider storing something like an iPod. You can store it at:<nobr> <wbr></nobr>/hardware/apple/ipod; or<nobr> <wbr></nobr>/apple/hardware/ipod</p><p>The former makes it very hard to find all the products that are made by apple (because you have to search other higher-level categories, like software, etc). The latter makes it very hard to find all hardware products for the same reason (you have to search<nobr> <wbr></nobr>/ibm/hardware,<nobr> <wbr></nobr>/microsoft/hardware, etc).</p><p>In a relational system, you'd just say something like "where vendor=apple" or "where category=hardware". The relational organization more closely resembles reality because the hierarchy is 100\% artificial.</p><p>I'm sure you can always find a particular set of queries that run faster on your favorite hierarchical or graph database system, but that's not the point. The point is that it biases the queries you ask (both in terms of ease and also efficiency) so heavily that the mixed queries found in most real businesses will cause problems for a hierarchical/graph databases system.</p><p><i>SQL can't handle most datastructures and complex relations, only very simple one dimensional ones</i></p><p>That shows ignorance of the relational model. Relations are n-dimensional, where n is the number of attributes.</p></htmltext>
<tokenext>Then design queries to answer questions such asThose questions can be answered quite easily using either a materialized path representation ( using something like ltree [ postgresql.org ] , or WITH ... RECURSIVE [ postgresql.org ] .Materialized path would be an efficient way to answer those questions .
However , if you try to use some graph or hierarchical database system , then that will be the only way you can efficiently access your data ; with a SQL system , it 's easier to allow the user to ask a variety of very different questions without bias toward any one particular type of question.Consider storing something like an iPod .
You can store it at : /hardware/apple/ipod ; or /apple/hardware/ipodThe former makes it very hard to find all the products that are made by apple ( because you have to search other higher-level categories , like software , etc ) .
The latter makes it very hard to find all hardware products for the same reason ( you have to search /ibm/hardware , /microsoft/hardware , etc ) .In a relational system , you 'd just say something like " where vendor = apple " or " where category = hardware " .
The relational organization more closely resembles reality because the hierarchy is 100 \ % artificial.I 'm sure you can always find a particular set of queries that run faster on your favorite hierarchical or graph database system , but that 's not the point .
The point is that it biases the queries you ask ( both in terms of ease and also efficiency ) so heavily that the mixed queries found in most real businesses will cause problems for a hierarchical/graph databases system.SQL ca n't handle most datastructures and complex relations , only very simple one dimensional onesThat shows ignorance of the relational model .
Relations are n-dimensional , where n is the number of attributes .</tokentext>
<sentencetext>Then design queries to answer questions such asThose questions can be answered quite easily using either a materialized path representation (using something like ltree [postgresql.org], or WITH ... RECURSIVE [postgresql.org].Materialized path would be an efficient way to answer those questions.
However, if you try to use some graph or hierarchical database system, then that will be the only way you can efficiently access your data; with a SQL system, it's easier to allow the user to ask a variety of very different questions without bias toward any one particular type of question.Consider storing something like an iPod.
You can store it at: /hardware/apple/ipod; or /apple/hardware/ipodThe former makes it very hard to find all the products that are made by apple (because you have to search other higher-level categories, like software, etc).
The latter makes it very hard to find all hardware products for the same reason (you have to search /ibm/hardware, /microsoft/hardware, etc).In a relational system, you'd just say something like "where vendor=apple" or "where category=hardware".
The relational organization more closely resembles reality because the hierarchy is 100\% artificial.I'm sure you can always find a particular set of queries that run faster on your favorite hierarchical or graph database system, but that's not the point.
The point is that it biases the queries you ask (both in terms of ease and also efficiency) so heavily that the mixed queries found in most real businesses will cause problems for a hierarchical/graph databases system.SQL can't handle most datastructures and complex relations, only very simple one dimensional onesThat shows ignorance of the relational model.
Relations are n-dimensional, where n is the number of attributes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565535</id>
	<title>How about saying yes to the alternative</title>
	<author>syousef</author>
	<datestamp>1246534620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Saying no to SQL and relational databases is just fine if you've got something better to replace it with. However I know of no such thing. The reason they're popular is that they are so powerful for data storage. If something better came along you wouldn't even need to say no to SQL. You'd just say yes to the newer better rival.</p></htmltext>
<tokenext>Saying no to SQL and relational databases is just fine if you 've got something better to replace it with .
However I know of no such thing .
The reason they 're popular is that they are so powerful for data storage .
If something better came along you would n't even need to say no to SQL .
You 'd just say yes to the newer better rival .</tokentext>
<sentencetext>Saying no to SQL and relational databases is just fine if you've got something better to replace it with.
However I know of no such thing.
The reason they're popular is that they are so powerful for data storage.
If something better came along you wouldn't even need to say no to SQL.
You'd just say yes to the newer better rival.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572503</id>
	<title>What do we learn from the answers here?</title>
	<author>drolli</author>
	<datestamp>1246640940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are some people who have reasonable objections against pressing data in a relational scheme because they really understand what it cant do for them and there are some people who have unreasonable objections against it because they really dont understand what it can do for them.</p></htmltext>
<tokenext>There are some people who have reasonable objections against pressing data in a relational scheme because they really understand what it cant do for them and there are some people who have unreasonable objections against it because they really dont understand what it can do for them .</tokentext>
<sentencetext>There are some people who have reasonable objections against pressing data in a relational scheme because they really understand what it cant do for them and there are some people who have unreasonable objections against it because they really dont understand what it can do for them.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565345
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567273
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566045
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567827
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_74</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566919
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571647
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567801
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569039
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_81</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568207
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571961
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_77</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565585
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_80</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565593
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_71</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566859
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570711
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568203
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565539
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565957
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566997
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578037
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_72</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565919
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568139
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_86</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570725
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574183
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565775
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566195
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565345
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568849
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569475
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565289
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565955
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28573983
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565535
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566995
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566203
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28583351
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_89</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28575737
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_92</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569505
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565775
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568585
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_88</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568787
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578125
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_85</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568379
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565627
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571577
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570485
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565497
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_84</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568953
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_75</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568261
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570079
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569765
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565269
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566297
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566245
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570167
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28663115
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565357
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572337
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572609
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28573801
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569653
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568119
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_90</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565727
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565941
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566515
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569379
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567609
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570189
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_78</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569157
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_83</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569301
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578153
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569891
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569945
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565613
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569111
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_73</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567003
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565289
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565955
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569003
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574729
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565527
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566973
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568305
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567017
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572669
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571663
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565703
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_93</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567501
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_76</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570719
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569005
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567445
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570329
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569807
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570317
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567905
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565869
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569999
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567355
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565641
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567113
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565749
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571511
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567643
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568847
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_87</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574837
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566273
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566373
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_91</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572517
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571815
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_79</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568343
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_82</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28584039
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572785
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574413
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570207
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569381
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_02_219247_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565357
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567087
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565143
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565615
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567113
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567445
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570189
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565367
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565521
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567801
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566911
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567643
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572609
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567905
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570329
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571663
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570711
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568847
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568207
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567609
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569381
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568203
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569157
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569945
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568343
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28573801
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570725
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569891
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569475
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568787
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569653
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566973
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568953
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578037
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572517
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570317
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566043
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569505
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568139
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567481
-----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28584039
-----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572785
-----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570719
-----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570485
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571511
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568119
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567003
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567017
-----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572669
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567501
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565613
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569111
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565531
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567355
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565555
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565371
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566373
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578125
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569765
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565869
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569999
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565703
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565701
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568379
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569005
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28583351
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28663115
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571815
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566919
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571647
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565475
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569301
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28578153
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565105
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567265
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569807
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567855
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569629
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570207
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571961
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574837
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574413
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569039
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568305
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571847
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565553
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565727
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565775
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566195
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568585
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567827
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28575737
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565627
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28571577
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566245
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570167
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568261
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28570079
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565357
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567087
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28572337
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565369
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565593
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574729
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565941
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566515
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569379
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565497
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565641
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565539
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565919
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566859
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565557
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565151
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565749
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566273
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566203
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565269
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566297
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565389
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565485
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565265
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565535
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566995
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565289
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565955
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28573983
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569003
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565227
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565865
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565957
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566997
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565199
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28574183
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565345
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28567273
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28568849
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565527
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28566045
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28565585
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_02_219247.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_02_219247.28569811
</commentlist>
</conversation>
