<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_28_1432234</id>
	<title>Why Some Devs Can't Wait For NoSQL To Die</title>
	<author>Soulskill</author>
	<datestamp>1269790140000</datestamp>
	<htmltext>theodp writes <i>"Ted Dziuba <a href="http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html">can't wait for NoSQL to die</a>. Developing your app for Google-sized scale, says Dziuba, is a waste of your time. Not to mention there is no way you will get it right. The sooner your company admits this, the sooner you can get down to some real work. If real businesses like Walmart can track all of their data in SQL databases that scale just fine, Dziuba argues, surely your company can, too."</i></htmltext>
<tokenext>theodp writes " Ted Dziuba ca n't wait for NoSQL to die .
Developing your app for Google-sized scale , says Dziuba , is a waste of your time .
Not to mention there is no way you will get it right .
The sooner your company admits this , the sooner you can get down to some real work .
If real businesses like Walmart can track all of their data in SQL databases that scale just fine , Dziuba argues , surely your company can , too .
"</tokentext>
<sentencetext>theodp writes "Ted Dziuba can't wait for NoSQL to die.
Developing your app for Google-sized scale, says Dziuba, is a waste of your time.
Not to mention there is no way you will get it right.
The sooner your company admits this, the sooner you can get down to some real work.
If real businesses like Walmart can track all of their data in SQL databases that scale just fine, Dziuba argues, surely your company can, too.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906</id>
	<title>XML (of databases)?</title>
	<author>Manip</author>
	<datestamp>1269796620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The company I work out is currently having a huge headache moving from files into databases. We currently store everything in XML which gives us a great amount of freedom and adaptability. However most database solutions fix you to a single (or handful) of data definitions. Which you can kind of re-create XML be defining all kinds of crazy relationships, it gets hugely convoluted (to say the least).</p><p>I would LOVE to see a document/XML-live database. Just needs to do things that standard databases support (e.g. Security Model, Easy Mirroring, Search/Queries) to make it worth our while moving at all. Last I checked we're up to 260,000 XML files and approx 40 different distinct file "formats" (XML layouts).</p></htmltext>
<tokenext>The company I work out is currently having a huge headache moving from files into databases .
We currently store everything in XML which gives us a great amount of freedom and adaptability .
However most database solutions fix you to a single ( or handful ) of data definitions .
Which you can kind of re-create XML be defining all kinds of crazy relationships , it gets hugely convoluted ( to say the least ) .I would LOVE to see a document/XML-live database .
Just needs to do things that standard databases support ( e.g .
Security Model , Easy Mirroring , Search/Queries ) to make it worth our while moving at all .
Last I checked we 're up to 260,000 XML files and approx 40 different distinct file " formats " ( XML layouts ) .</tokentext>
<sentencetext>The company I work out is currently having a huge headache moving from files into databases.
We currently store everything in XML which gives us a great amount of freedom and adaptability.
However most database solutions fix you to a single (or handful) of data definitions.
Which you can kind of re-create XML be defining all kinds of crazy relationships, it gets hugely convoluted (to say the least).I would LOVE to see a document/XML-live database.
Just needs to do things that standard databases support (e.g.
Security Model, Easy Mirroring, Search/Queries) to make it worth our while moving at all.
Last I checked we're up to 260,000 XML files and approx 40 different distinct file "formats" (XML layouts).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</id>
	<title>The Article Is Right...  And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269796140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Real business track their data with SQL databases, true.  However, real businesses have small numbers of transactions relative to their value.  If Walmart had the same revenue but the average sale was a tenth of a cent, their fancy SQL database would be smouldering rubble.</p><p>That's what Facebook and Twitter and other large social media sites are facing.  Just try running Twitter's volume and Twitter's page hits and API hits off MySQL.  It doesn't matter how many replicas you run, it's not going to work.  Maybe you could run it on a cluster of IBM Z-series mainframes running DB2 - but where is the money going to come from?</p><p>Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways.  They won't work for Walmart, but they'll do the job just fine for Facebook and Twitter.  If you have those specific scaling problems and can live with the restrictions (you lose ACID, indexes, and joins to varying degrees) then they'll work for you.</p><p>If all you know is that your site is running slow, then implementing NoSQL is unlikely to improve things.</p></htmltext>
<tokenext>Real business track their data with SQL databases , true .
However , real businesses have small numbers of transactions relative to their value .
If Walmart had the same revenue but the average sale was a tenth of a cent , their fancy SQL database would be smouldering rubble.That 's what Facebook and Twitter and other large social media sites are facing .
Just try running Twitter 's volume and Twitter 's page hits and API hits off MySQL .
It does n't matter how many replicas you run , it 's not going to work .
Maybe you could run it on a cluster of IBM Z-series mainframes running DB2 - but where is the money going to come from ? Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways .
They wo n't work for Walmart , but they 'll do the job just fine for Facebook and Twitter .
If you have those specific scaling problems and can live with the restrictions ( you lose ACID , indexes , and joins to varying degrees ) then they 'll work for you.If all you know is that your site is running slow , then implementing NoSQL is unlikely to improve things .</tokentext>
<sentencetext>Real business track their data with SQL databases, true.
However, real businesses have small numbers of transactions relative to their value.
If Walmart had the same revenue but the average sale was a tenth of a cent, their fancy SQL database would be smouldering rubble.That's what Facebook and Twitter and other large social media sites are facing.
Just try running Twitter's volume and Twitter's page hits and API hits off MySQL.
It doesn't matter how many replicas you run, it's not going to work.
Maybe you could run it on a cluster of IBM Z-series mainframes running DB2 - but where is the money going to come from?Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways.
They won't work for Walmart, but they'll do the job just fine for Facebook and Twitter.
If you have those specific scaling problems and can live with the restrictions (you lose ACID, indexes, and joins to varying degrees) then they'll work for you.If all you know is that your site is running slow, then implementing NoSQL is unlikely to improve things.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647896</id>
	<title>Walmart's primary business isn't online</title>
	<author>Anonymous</author>
	<datestamp>1269796440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Walmart's primary business isn't online. No comparison.</p></htmltext>
<tokenext>Walmart 's primary business is n't online .
No comparison .</tokentext>
<sentencetext>Walmart's primary business isn't online.
No comparison.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651396</id>
	<title>In other news ...</title>
	<author>yelvington</author>
	<datestamp>1269778440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In other news, some random hammer enthusiast posted on his blog that he just can't wait for screwdrivers to die.</p></htmltext>
<tokenext>In other news , some random hammer enthusiast posted on his blog that he just ca n't wait for screwdrivers to die .</tokentext>
<sentencetext>In other news, some random hammer enthusiast posted on his blog that he just can't wait for screwdrivers to die.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648196</id>
	<title>Re:XML (of databases)?</title>
	<author>kronosopher</author>
	<datestamp>1269798600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>use an object relational mapper or something similar to generate interoperable database/xml schematics.. you should be able to write conversion scripts pretty easily that way.  In so far as mirroring and xml and sql datastores, I'm not sure if such a solution exists.</htmltext>
<tokenext>use an object relational mapper or something similar to generate interoperable database/xml schematics.. you should be able to write conversion scripts pretty easily that way .
In so far as mirroring and xml and sql datastores , I 'm not sure if such a solution exists .</tokentext>
<sentencetext>use an object relational mapper or something similar to generate interoperable database/xml schematics.. you should be able to write conversion scripts pretty easily that way.
In so far as mirroring and xml and sql datastores, I'm not sure if such a solution exists.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</id>
	<title>Some people just want the holy grail</title>
	<author>SmallFurryCreature</author>
	<datestamp>1269796440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I think some developers keep looking for the holy grail. Some magical solution that will turn development from punching in code, to Star Trek: "Computer do my job for me please".
</p><p>Template languages, 4GL, NoSQL, Ruby on Rails... it is all part of an attempt to take the nasty out of development and they all... well... they all just don't really happen.
</p><p>Because deep down, with all the frameworks and generators, if you want your code to do what you want it to do, you are still writing out if statements a lot.
</p><p>And yes, OO and such also belong to this. Not the concept themselves, but the way most people talk about. OO means code re-use right?
</p><p>If you said yes, then you are a manager, go put on your tie, you will never be any good at coding.
</p><p>You can re-use all code. And it has been done for a long time.
</p><p>What, did you think that people who wrote basic for the C64 went "Oh I wrote this bit of code for printing, now I need the same functionality, I am going to write it all over again!"
</p><p>OO does make code re-use a bit easier BUT that is NOT the claim that people often make. Trust me, I ask this in interviews and it is always the same answer. Apparently you can't re-use functions. No way, no how. NEXT!
</p><p>I see two kind of developers. Those who hate their job and those who don't. The former want to be managers, get away from writing code as fast as possible. And they will leap on anything that seems to make their jobs easier. Meanwhile the rest of us go on with actually producing stuff.
</p><p>Just check, how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you don't need to write another line of code ever!</p></htmltext>
<tokenext>I think some developers keep looking for the holy grail .
Some magical solution that will turn development from punching in code , to Star Trek : " Computer do my job for me please " .
Template languages , 4GL , NoSQL , Ruby on Rails... it is all part of an attempt to take the nasty out of development and they all... well... they all just do n't really happen .
Because deep down , with all the frameworks and generators , if you want your code to do what you want it to do , you are still writing out if statements a lot .
And yes , OO and such also belong to this .
Not the concept themselves , but the way most people talk about .
OO means code re-use right ?
If you said yes , then you are a manager , go put on your tie , you will never be any good at coding .
You can re-use all code .
And it has been done for a long time .
What , did you think that people who wrote basic for the C64 went " Oh I wrote this bit of code for printing , now I need the same functionality , I am going to write it all over again !
" OO does make code re-use a bit easier BUT that is NOT the claim that people often make .
Trust me , I ask this in interviews and it is always the same answer .
Apparently you ca n't re-use functions .
No way , no how .
NEXT ! I see two kind of developers .
Those who hate their job and those who do n't .
The former want to be managers , get away from writing code as fast as possible .
And they will leap on anything that seems to make their jobs easier .
Meanwhile the rest of us go on with actually producing stuff .
Just check , how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you do n't need to write another line of code ever !</tokentext>
<sentencetext>I think some developers keep looking for the holy grail.
Some magical solution that will turn development from punching in code, to Star Trek: "Computer do my job for me please".
Template languages, 4GL, NoSQL, Ruby on Rails... it is all part of an attempt to take the nasty out of development and they all... well... they all just don't really happen.
Because deep down, with all the frameworks and generators, if you want your code to do what you want it to do, you are still writing out if statements a lot.
And yes, OO and such also belong to this.
Not the concept themselves, but the way most people talk about.
OO means code re-use right?
If you said yes, then you are a manager, go put on your tie, you will never be any good at coding.
You can re-use all code.
And it has been done for a long time.
What, did you think that people who wrote basic for the C64 went "Oh I wrote this bit of code for printing, now I need the same functionality, I am going to write it all over again!
"
OO does make code re-use a bit easier BUT that is NOT the claim that people often make.
Trust me, I ask this in interviews and it is always the same answer.
Apparently you can't re-use functions.
No way, no how.
NEXT!
I see two kind of developers.
Those who hate their job and those who don't.
The former want to be managers, get away from writing code as fast as possible.
And they will leap on anything that seems to make their jobs easier.
Meanwhile the rest of us go on with actually producing stuff.
Just check, how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you don't need to write another line of code ever!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648620</id>
	<title>depends on the problem</title>
	<author>dominux</author>
	<datestamp>1269801720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>relational databases are great if you have a relational problem. For everything else there is NoSQL. It is surprising how much of the world's data looks like "a stack of documents" rather than "a collection of mathematically related sets of data" Lotus Notes was the only NoSQL player for 20 years, now there are lots. Notes sucked because it had no competitors, the concept was and is sound. Now there is competition and lots of NoSQL database systems and application environments on top that suck less and less by the day.</htmltext>
<tokenext>relational databases are great if you have a relational problem .
For everything else there is NoSQL .
It is surprising how much of the world 's data looks like " a stack of documents " rather than " a collection of mathematically related sets of data " Lotus Notes was the only NoSQL player for 20 years , now there are lots .
Notes sucked because it had no competitors , the concept was and is sound .
Now there is competition and lots of NoSQL database systems and application environments on top that suck less and less by the day .</tokentext>
<sentencetext>relational databases are great if you have a relational problem.
For everything else there is NoSQL.
It is surprising how much of the world's data looks like "a stack of documents" rather than "a collection of mathematically related sets of data" Lotus Notes was the only NoSQL player for 20 years, now there are lots.
Notes sucked because it had no competitors, the concept was and is sound.
Now there is competition and lots of NoSQL database systems and application environments on top that suck less and less by the day.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649984</id>
	<title>hammer - all nails</title>
	<author>kalman5</author>
	<datestamp>1269768300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>As soon people have an hammer on their hands, all the stuffs they see around are nails. The good IT worker is the one with different tools on his hands with the ability to choose the right one at the right time, and before you forget it remember that premature optimization is the root of all evil.</htmltext>
<tokenext>As soon people have an hammer on their hands , all the stuffs they see around are nails .
The good IT worker is the one with different tools on his hands with the ability to choose the right one at the right time , and before you forget it remember that premature optimization is the root of all evil .</tokentext>
<sentencetext>As soon people have an hammer on their hands, all the stuffs they see around are nails.
The good IT worker is the one with different tools on his hands with the ability to choose the right one at the right time, and before you forget it remember that premature optimization is the root of all evil.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650398</id>
	<title>even if you are not Google...</title>
	<author>pydev</author>
	<datestamp>1269771480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>It's easy to hit intrinsic performance limits with SQL databases even on small apps.  And for people who aren't database experts, it's even easier since they don't know the hoops to jump through to make their SQL databases perform well.  For the average programmer, it's easier to get good performance out of no-SQL databases.</p><p>Using SQL databases programmatically is a fairly silly notion to begin with: SQL was originally intended as an easy-to-use query language for non-experts because people were having trouble with navigating data structures.  But programmers are excellent at navigating data structures and designing efficient data structures.  SQL is solving a problem that most programmers don't have, and you're paying a big performance penalty for that.</p><p>Sometimes an SQL database is the right thing to use, sometimes it isn't.  People really need to use their head instead of blindly picking one or the other solution.</p></htmltext>
<tokenext>It 's easy to hit intrinsic performance limits with SQL databases even on small apps .
And for people who are n't database experts , it 's even easier since they do n't know the hoops to jump through to make their SQL databases perform well .
For the average programmer , it 's easier to get good performance out of no-SQL databases.Using SQL databases programmatically is a fairly silly notion to begin with : SQL was originally intended as an easy-to-use query language for non-experts because people were having trouble with navigating data structures .
But programmers are excellent at navigating data structures and designing efficient data structures .
SQL is solving a problem that most programmers do n't have , and you 're paying a big performance penalty for that.Sometimes an SQL database is the right thing to use , sometimes it is n't .
People really need to use their head instead of blindly picking one or the other solution .</tokentext>
<sentencetext>It's easy to hit intrinsic performance limits with SQL databases even on small apps.
And for people who aren't database experts, it's even easier since they don't know the hoops to jump through to make their SQL databases perform well.
For the average programmer, it's easier to get good performance out of no-SQL databases.Using SQL databases programmatically is a fairly silly notion to begin with: SQL was originally intended as an easy-to-use query language for non-experts because people were having trouble with navigating data structures.
But programmers are excellent at navigating data structures and designing efficient data structures.
SQL is solving a problem that most programmers don't have, and you're paying a big performance penalty for that.Sometimes an SQL database is the right thing to use, sometimes it isn't.
People really need to use their head instead of blindly picking one or the other solution.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650360</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Anonymous</author>
	<datestamp>1269771240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Actually you can extend functions. With advice or pre- or post methods. At least in certain languages...</p></htmltext>
<tokenext>Actually you can extend functions .
With advice or pre- or post methods .
At least in certain languages.. .</tokentext>
<sentencetext>Actually you can extend functions.
With advice or pre- or post methods.
At least in certain languages...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652682</id>
	<title>TokyoCabinet</title>
	<author>Kagetsuki</author>
	<datestamp>1269790500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Our company has saved immense time and made our applications faster and easier to understand, as well as [theoretically] more secure by switching to Tokyo Cabinet. F*ck SQL and F*ck MySQL especially. I personally wrote some of the interfaces to the TokyoCabinet databases we are using and at this point I have decided I never want to do anything with SQL ever again. Seriously, SQL sucks - it's clunky, easy to introduce security flaws, slow, breaks easily, difficult to access from multiple languages simultaneously, you often have to do things like create special users to do certain things which then introduced more security risk... and on and on. SQL is crappy and should be considered deprecated.</htmltext>
<tokenext>Our company has saved immense time and made our applications faster and easier to understand , as well as [ theoretically ] more secure by switching to Tokyo Cabinet .
F * ck SQL and F * ck MySQL especially .
I personally wrote some of the interfaces to the TokyoCabinet databases we are using and at this point I have decided I never want to do anything with SQL ever again .
Seriously , SQL sucks - it 's clunky , easy to introduce security flaws , slow , breaks easily , difficult to access from multiple languages simultaneously , you often have to do things like create special users to do certain things which then introduced more security risk... and on and on .
SQL is crappy and should be considered deprecated .</tokentext>
<sentencetext>Our company has saved immense time and made our applications faster and easier to understand, as well as [theoretically] more secure by switching to Tokyo Cabinet.
F*ck SQL and F*ck MySQL especially.
I personally wrote some of the interfaces to the TokyoCabinet databases we are using and at this point I have decided I never want to do anything with SQL ever again.
Seriously, SQL sucks - it's clunky, easy to introduce security flaws, slow, breaks easily, difficult to access from multiple languages simultaneously, you often have to do things like create special users to do certain things which then introduced more security risk... and on and on.
SQL is crappy and should be considered deprecated.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648610</id>
	<title>Storage as a Service</title>
	<author>Qwavel</author>
	<datestamp>1269801600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>The article focuses on NoSQL's claim to scalability, but isn't that just one of the features of (some of the) NoSQL options?</p><p>Google, Amazon, and Microsoft all provide NoSQL storage as a service that is easy to use and cheap, particularly for getting started.  Those are two pretty important features and I would imagine that it is those features, rather then dreams of needing vast scalability, that attract the many web startups.</p></htmltext>
<tokenext>The article focuses on NoSQL 's claim to scalability , but is n't that just one of the features of ( some of the ) NoSQL options ? Google , Amazon , and Microsoft all provide NoSQL storage as a service that is easy to use and cheap , particularly for getting started .
Those are two pretty important features and I would imagine that it is those features , rather then dreams of needing vast scalability , that attract the many web startups .</tokentext>
<sentencetext>The article focuses on NoSQL's claim to scalability, but isn't that just one of the features of (some of the) NoSQL options?Google, Amazon, and Microsoft all provide NoSQL storage as a service that is easy to use and cheap, particularly for getting started.
Those are two pretty important features and I would imagine that it is those features, rather then dreams of needing vast scalability, that attract the many web startups.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651410</id>
	<title>Re:Some people just want the holy grail</title>
	<author>sproketboy</author>
	<datestamp>1269778560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I wish I had mod points. Good post.</p></htmltext>
<tokenext>I wish I had mod points .
Good post .</tokentext>
<sentencetext>I wish I had mod points.
Good post.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648078</id>
	<title>Re:XML (of databases)?</title>
	<author>Gorath99</author>
	<datestamp>1269797820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Have you checked out something like <a href="http://www.oracle.com/technology/tech/xml/xmldb/index.html" title="oracle.com">XML DB</a> [oracle.com]? I haven't used it much myself, but it sounds like it may meet your needs. It comes bundled with the <a href="http://www.oracle.com/technology/products/database/xe/index.html" title="oracle.com">XE database</a> [oracle.com], which is free as in beer. (But XE has some limitations that the enterprise product doesn't have, of course.)</p><p>Disclaimer: I work for Oracle.</p></htmltext>
<tokenext>Have you checked out something like XML DB [ oracle.com ] ?
I have n't used it much myself , but it sounds like it may meet your needs .
It comes bundled with the XE database [ oracle.com ] , which is free as in beer .
( But XE has some limitations that the enterprise product does n't have , of course .
) Disclaimer : I work for Oracle .</tokentext>
<sentencetext>Have you checked out something like XML DB [oracle.com]?
I haven't used it much myself, but it sounds like it may meet your needs.
It comes bundled with the XE database [oracle.com], which is free as in beer.
(But XE has some limitations that the enterprise product doesn't have, of course.
)Disclaimer: I work for Oracle.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649190</id>
	<title>Walmart huh/</title>
	<author>iCEBaLM</author>
	<datestamp>1269805380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>If real businesses like Walmart can track all of their data in SQL databases that scale just fine, Dziuba argues, surely your company can, too.</i></p><p>Oddly enough I'm trying to get to walmart.ca right now, and it's down....</p></htmltext>
<tokenext>If real businesses like Walmart can track all of their data in SQL databases that scale just fine , Dziuba argues , surely your company can , too.Oddly enough I 'm trying to get to walmart.ca right now , and it 's down... .</tokentext>
<sentencetext>If real businesses like Walmart can track all of their data in SQL databases that scale just fine, Dziuba argues, surely your company can, too.Oddly enough I'm trying to get to walmart.ca right now, and it's down....</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648068</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Vellmont</author>
	<datestamp>1269797760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>In some ways I agree with the general idea of your post.  But stepping back a bit, code HAS gotten easier to write over the long term.  I'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly.  Those advancements in language came through a lot of trial and error (a lot of error).  How many failed language exist that turned out to be dead ends (though spurred further advancements and refinements?).  How do you know the technologies you mentioned won't turn into the next (your favorite productive language here)?</p><p>You're right that endlessly pursuing the latest trend is just foolhardy, as most "new latest greatest technology" turn out to be duds.  The point being those duds sometimes DO pan out.  Anyone that thinks that relational databases are the end-all-be-all of persistent data storage hasn't done enough relational database development to understand some of the limitations.</p></htmltext>
<tokenext>In some ways I agree with the general idea of your post .
But stepping back a bit , code HAS gotten easier to write over the long term .
I 'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly .
Those advancements in language came through a lot of trial and error ( a lot of error ) .
How many failed language exist that turned out to be dead ends ( though spurred further advancements and refinements ? ) .
How do you know the technologies you mentioned wo n't turn into the next ( your favorite productive language here ) ? You 're right that endlessly pursuing the latest trend is just foolhardy , as most " new latest greatest technology " turn out to be duds .
The point being those duds sometimes DO pan out .
Anyone that thinks that relational databases are the end-all-be-all of persistent data storage has n't done enough relational database development to understand some of the limitations .</tokentext>
<sentencetext>In some ways I agree with the general idea of your post.
But stepping back a bit, code HAS gotten easier to write over the long term.
I'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly.
Those advancements in language came through a lot of trial and error (a lot of error).
How many failed language exist that turned out to be dead ends (though spurred further advancements and refinements?).
How do you know the technologies you mentioned won't turn into the next (your favorite productive language here)?You're right that endlessly pursuing the latest trend is just foolhardy, as most "new latest greatest technology" turn out to be duds.
The point being those duds sometimes DO pan out.
Anyone that thinks that relational databases are the end-all-be-all of persistent data storage hasn't done enough relational database development to understand some of the limitations.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653900</id>
	<title>It's not about "technology" purity.</title>
	<author>xyourfacekillerx</author>
	<datestamp>1269804300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Look, guys. Let's be honest here. NoSQL has been around forever; it's the default approach for data storage unless a relational database is selected as a requirement of the software being written (am I the only one who still writes his own file formats and uses record-based random access for small-time data storage? If you don't need the complexity of XML or SQL, then don't use it...)
<br> <br>
That being said, NoSQL is just giving that obvious practice a name as if it is a new phenomenon in the development world. Agreed now that it has a name it tends to mislead developers into discarding SQL DBMS irresponsibly, but it does serve an extremely important purpose in the business world: It superficially inflates an otherwise vacuous business process, which under the guise of "innovation", drives business demand.
<br> <br>
The IT world does this all the time. They re-package existing solutions, or disrupt them in favor of "new" solutions which to be honest are often unnecessary and more complex than the original solutions. But it drives business. It creates new hardware, new software, new job positions, new education criteria that academia can sell and creditors and government can tax, new system maintenance and migration hurdles; it turns businesses into consumers, it creates new consumers for those businesses, and justifies continuing relationships with consumers when the last product was already good enough.
<br> <br>
The mere hype of IT "solutions", however irrelevant or pointless or unnecessary, perpetuates the industry. A lot of it is utter BS. It's all they can do during times when few real advancements are made... and sadly it works too well... and that is the REAL problem with the NoSQL trend. Not bad programming practice. Just artificial business fuel.</htmltext>
<tokenext>Look , guys .
Let 's be honest here .
NoSQL has been around forever ; it 's the default approach for data storage unless a relational database is selected as a requirement of the software being written ( am I the only one who still writes his own file formats and uses record-based random access for small-time data storage ?
If you do n't need the complexity of XML or SQL , then do n't use it... ) That being said , NoSQL is just giving that obvious practice a name as if it is a new phenomenon in the development world .
Agreed now that it has a name it tends to mislead developers into discarding SQL DBMS irresponsibly , but it does serve an extremely important purpose in the business world : It superficially inflates an otherwise vacuous business process , which under the guise of " innovation " , drives business demand .
The IT world does this all the time .
They re-package existing solutions , or disrupt them in favor of " new " solutions which to be honest are often unnecessary and more complex than the original solutions .
But it drives business .
It creates new hardware , new software , new job positions , new education criteria that academia can sell and creditors and government can tax , new system maintenance and migration hurdles ; it turns businesses into consumers , it creates new consumers for those businesses , and justifies continuing relationships with consumers when the last product was already good enough .
The mere hype of IT " solutions " , however irrelevant or pointless or unnecessary , perpetuates the industry .
A lot of it is utter BS .
It 's all they can do during times when few real advancements are made... and sadly it works too well... and that is the REAL problem with the NoSQL trend .
Not bad programming practice .
Just artificial business fuel .</tokentext>
<sentencetext>Look, guys.
Let's be honest here.
NoSQL has been around forever; it's the default approach for data storage unless a relational database is selected as a requirement of the software being written (am I the only one who still writes his own file formats and uses record-based random access for small-time data storage?
If you don't need the complexity of XML or SQL, then don't use it...)
 
That being said, NoSQL is just giving that obvious practice a name as if it is a new phenomenon in the development world.
Agreed now that it has a name it tends to mislead developers into discarding SQL DBMS irresponsibly, but it does serve an extremely important purpose in the business world: It superficially inflates an otherwise vacuous business process, which under the guise of "innovation", drives business demand.
The IT world does this all the time.
They re-package existing solutions, or disrupt them in favor of "new" solutions which to be honest are often unnecessary and more complex than the original solutions.
But it drives business.
It creates new hardware, new software, new job positions, new education criteria that academia can sell and creditors and government can tax, new system maintenance and migration hurdles; it turns businesses into consumers, it creates new consumers for those businesses, and justifies continuing relationships with consumers when the last product was already good enough.
The mere hype of IT "solutions", however irrelevant or pointless or unnecessary, perpetuates the industry.
A lot of it is utter BS.
It's all they can do during times when few real advancements are made... and sadly it works too well... and that is the REAL problem with the NoSQL trend.
Not bad programming practice.
Just artificial business fuel.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649622</id>
	<title>Future Data Storage</title>
	<author>prefec2</author>
	<datestamp>1269808740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Today many people store data on their private machine using classic file systems and they use databases to store files and to tag them. In future tags or other kinds of attributes will become more important in information storage and retrieval. Therefor we need databases capable of managing such information. RDMS are very good at storing such information and to work with sets and subsets. And tags and attributes of objects/files/entities are nothing more than markers that show to which sets objects belong. So I doubt that SQL databases will go away.</p><p>Furthermore, objects in OOP languages are very restrictive. If you look for example at objects (called individuals) in OWL, you can see that data objects can have properties and relationships to other objects which cannot be expressed that easily in OOP language style. Therefor using DBs which are limited by the object model of OOP languages will not suffice.</p></htmltext>
<tokenext>Today many people store data on their private machine using classic file systems and they use databases to store files and to tag them .
In future tags or other kinds of attributes will become more important in information storage and retrieval .
Therefor we need databases capable of managing such information .
RDMS are very good at storing such information and to work with sets and subsets .
And tags and attributes of objects/files/entities are nothing more than markers that show to which sets objects belong .
So I doubt that SQL databases will go away.Furthermore , objects in OOP languages are very restrictive .
If you look for example at objects ( called individuals ) in OWL , you can see that data objects can have properties and relationships to other objects which can not be expressed that easily in OOP language style .
Therefor using DBs which are limited by the object model of OOP languages will not suffice .</tokentext>
<sentencetext>Today many people store data on their private machine using classic file systems and they use databases to store files and to tag them.
In future tags or other kinds of attributes will become more important in information storage and retrieval.
Therefor we need databases capable of managing such information.
RDMS are very good at storing such information and to work with sets and subsets.
And tags and attributes of objects/files/entities are nothing more than markers that show to which sets objects belong.
So I doubt that SQL databases will go away.Furthermore, objects in OOP languages are very restrictive.
If you look for example at objects (called individuals) in OWL, you can see that data objects can have properties and relationships to other objects which cannot be expressed that easily in OOP language style.
Therefor using DBs which are limited by the object model of OOP languages will not suffice.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648680</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Anonymous</author>
	<datestamp>1269802140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ofcourse you can extend functions, its node all the time. OO is jut a very nice encapsulation trick that spares you the trouble of shifting data about.</p></htmltext>
<tokenext>Ofcourse you can extend functions , its node all the time .
OO is jut a very nice encapsulation trick that spares you the trouble of shifting data about .</tokentext>
<sentencetext>Ofcourse you can extend functions, its node all the time.
OO is jut a very nice encapsulation trick that spares you the trouble of shifting data about.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648658</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Vellmont</author>
	<datestamp>1269801900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i><br>You can reuse functions but you can't extend them and that's where OOs reuse shines. It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.<br></i><br>With each new tool brings a new way to abuse it.  What I'd add is that for code re-use to work (in whatever language) you have to design it to be reused in the first place.  A function written by a halfway decent developer with at least some re-use in mind is going to be 10 times better than a shitty OO object designed by what I call a "get the cookie" developer.</p></htmltext>
<tokenext>You can reuse functions but you ca n't extend them and that 's where OOs reuse shines .
It 's very powerful to be able to lay out your code as a tree and control the reuse 'flow ' at the nodes.With each new tool brings a new way to abuse it .
What I 'd add is that for code re-use to work ( in whatever language ) you have to design it to be reused in the first place .
A function written by a halfway decent developer with at least some re-use in mind is going to be 10 times better than a shitty OO object designed by what I call a " get the cookie " developer .</tokentext>
<sentencetext>You can reuse functions but you can't extend them and that's where OOs reuse shines.
It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.With each new tool brings a new way to abuse it.
What I'd add is that for code re-use to work (in whatever language) you have to design it to be reused in the first place.
A function written by a halfway decent developer with at least some re-use in mind is going to be 10 times better than a shitty OO object designed by what I call a "get the cookie" developer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31663192</id>
	<title>NoSQL is nothing revolutionary</title>
	<author>reich</author>
	<datestamp>1269861600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Ugh.</p><p>The saddest part to me about the "new hotness" of NoSQL zealots is that a scalable, fast, flexible key-value store isn't new at all.  It's called LDAP.  Sadly, it's continues to be a horribly misunderstood beast.  Yes, it's more than a shared address book.</p><p>In the end, you use the right tool for the job.  SQL is relational.  LDAP is hierarchical.  Neither is new hotness, so stop pretending to invent.  Both perform their jobs exceptionally well.... if you use them for the job they are intended, and learn a little something about the concepts invented before your birth.   Chances are, they've been thought through before, and you're being lazy.  Go read up.</p></htmltext>
<tokenext>Ugh.The saddest part to me about the " new hotness " of NoSQL zealots is that a scalable , fast , flexible key-value store is n't new at all .
It 's called LDAP .
Sadly , it 's continues to be a horribly misunderstood beast .
Yes , it 's more than a shared address book.In the end , you use the right tool for the job .
SQL is relational .
LDAP is hierarchical .
Neither is new hotness , so stop pretending to invent .
Both perform their jobs exceptionally well.... if you use them for the job they are intended , and learn a little something about the concepts invented before your birth .
Chances are , they 've been thought through before , and you 're being lazy .
Go read up .</tokentext>
<sentencetext>Ugh.The saddest part to me about the "new hotness" of NoSQL zealots is that a scalable, fast, flexible key-value store isn't new at all.
It's called LDAP.
Sadly, it's continues to be a horribly misunderstood beast.
Yes, it's more than a shared address book.In the end, you use the right tool for the job.
SQL is relational.
LDAP is hierarchical.
Neither is new hotness, so stop pretending to invent.
Both perform their jobs exceptionally well.... if you use them for the job they are intended, and learn a little something about the concepts invented before your birth.
Chances are, they've been thought through before, and you're being lazy.
Go read up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648020</id>
	<title>The NoSQL debate never gives any real information</title>
	<author>i\_ate\_god</author>
	<datestamp>1269797340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>At first, I thought NoSQL like Cassandra should simply be used as a store for precomputed relationships. Then I thought NoSQL was just a structureless store that can scale in any given direction with no effort.</p><p>Both sound interesting, but then the debate against NoSQL is just "well, SQL can already do all that, but you get data integrity with it. If it doesn't scale, then just build a manly man's server and it will".</p><p>So, I dunno. The whole debate has gotten very religious very quickly and as a result, no one is really doing a proper comparison because no one seems to take the approach of "right tool for the right job, so here are the jobs NoSQL Is right for, and here are the jobs your RDBMS is good for".</p></htmltext>
<tokenext>At first , I thought NoSQL like Cassandra should simply be used as a store for precomputed relationships .
Then I thought NoSQL was just a structureless store that can scale in any given direction with no effort.Both sound interesting , but then the debate against NoSQL is just " well , SQL can already do all that , but you get data integrity with it .
If it does n't scale , then just build a manly man 's server and it will " .So , I dunno .
The whole debate has gotten very religious very quickly and as a result , no one is really doing a proper comparison because no one seems to take the approach of " right tool for the right job , so here are the jobs NoSQL Is right for , and here are the jobs your RDBMS is good for " .</tokentext>
<sentencetext>At first, I thought NoSQL like Cassandra should simply be used as a store for precomputed relationships.
Then I thought NoSQL was just a structureless store that can scale in any given direction with no effort.Both sound interesting, but then the debate against NoSQL is just "well, SQL can already do all that, but you get data integrity with it.
If it doesn't scale, then just build a manly man's server and it will".So, I dunno.
The whole debate has gotten very religious very quickly and as a result, no one is really doing a proper comparison because no one seems to take the approach of "right tool for the right job, so here are the jobs NoSQL Is right for, and here are the jobs your RDBMS is good for".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651114</id>
	<title>COBOL rules!</title>
	<author>Anonymous</author>
	<datestamp>1269776160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>What was wrong with COBOL?  Didn't it solve most of businesses problems?  What makes C/C#/C++/Java/Ruby/Perl/PHP so much better?</p></htmltext>
<tokenext>What was wrong with COBOL ?
Did n't it solve most of businesses problems ?
What makes C/C # /C + + /Java/Ruby/Perl/PHP so much better ?</tokentext>
<sentencetext>What was wrong with COBOL?
Didn't it solve most of businesses problems?
What makes C/C#/C++/Java/Ruby/Perl/PHP so much better?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647942</id>
	<title>Agree with other posters</title>
	<author>daveb1</author>
	<datestamp>1269796920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Agree with other posters. sql is a tool.
The point about nosql is that is is a different tool.
ACID in a database is fine normally. However, if you can live without it, which many can, do so!</htmltext>
<tokenext>Agree with other posters .
sql is a tool .
The point about nosql is that is is a different tool .
ACID in a database is fine normally .
However , if you can live without it , which many can , do so !</tokentext>
<sentencetext>Agree with other posters.
sql is a tool.
The point about nosql is that is is a different tool.
ACID in a database is fine normally.
However, if you can live without it, which many can, do so!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648234</id>
	<title>I'm Still Fuzzy on NoSQL</title>
	<author>RAMMS+EIN</author>
	<datestamp>1269798900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>I'm still fuzzy on what NoSQL is supposed to be and what it is supposed to bring to the table.</p><p>From what I've understood, it's basically a common banner for various different databases that all share the common property of not being relational databases and not providing ACID guarantees.</p><p>If so, it seems to me that the whole NoSQL vs. <a href="http://en.wikipedia.org/wiki/Relational\_database\_management\_system" title="wikipedia.org">RDMBS</a> [wikipedia.org] debate is about a false dichotomy. There are some applications where a relational database is the right tool for the job, and there are some where a relational database is not the right tool for the job. In some of those latter cases, one of the NoSQL databases may be the right thing.</p><p>This is nothing new. Non-relational databases have been used on Unix for a long time, and are even a standard part of POSIX (see for example <a href="http://www.opengroup.org/onlinepubs/9699919799/functions/dbm\_open.html" title="opengroup.org">the manpage for dbm\_open</a> [opengroup.org]). It's also long been known that, for example, <a href="http://www.oracle.com/database/berkeley-db/index.html" title="oracle.com">Berkeley DB</a> [oracle.com] can be a lot faster than an RDBMS - as long as your application doesn't make use of all the features an RDBMS provides. Lots of programs even don't use one of these database systems, but invent their own, custom format. <a href="http://git-scm.com/" title="git-scm.com">Git</a> [git-scm.com] is a very successful example of this.</p><p>To me, it seems that what we are seeing here is loads of people who had learned to use relational databases for all their storage needs discovering that there are other ways to store data, and that one of those methods may work better than an RDMBS for a particular application. Well, yes. Does that surprise anyone? It sure doesn't surprise me. Does it mean that RDMBSes are now useless? Not at all. Does it mean you should use a non-relational storage system where this makes more sense? Of course! Now, can we please get back to work? I don't see the point of having a holy war over whether RDBMS or NoSQL is better, when common sense says that they both have their uses.</p></htmltext>
<tokenext>I 'm still fuzzy on what NoSQL is supposed to be and what it is supposed to bring to the table.From what I 've understood , it 's basically a common banner for various different databases that all share the common property of not being relational databases and not providing ACID guarantees.If so , it seems to me that the whole NoSQL vs. RDMBS [ wikipedia.org ] debate is about a false dichotomy .
There are some applications where a relational database is the right tool for the job , and there are some where a relational database is not the right tool for the job .
In some of those latter cases , one of the NoSQL databases may be the right thing.This is nothing new .
Non-relational databases have been used on Unix for a long time , and are even a standard part of POSIX ( see for example the manpage for dbm \ _open [ opengroup.org ] ) .
It 's also long been known that , for example , Berkeley DB [ oracle.com ] can be a lot faster than an RDBMS - as long as your application does n't make use of all the features an RDBMS provides .
Lots of programs even do n't use one of these database systems , but invent their own , custom format .
Git [ git-scm.com ] is a very successful example of this.To me , it seems that what we are seeing here is loads of people who had learned to use relational databases for all their storage needs discovering that there are other ways to store data , and that one of those methods may work better than an RDMBS for a particular application .
Well , yes .
Does that surprise anyone ?
It sure does n't surprise me .
Does it mean that RDMBSes are now useless ?
Not at all .
Does it mean you should use a non-relational storage system where this makes more sense ?
Of course !
Now , can we please get back to work ?
I do n't see the point of having a holy war over whether RDBMS or NoSQL is better , when common sense says that they both have their uses .</tokentext>
<sentencetext>I'm still fuzzy on what NoSQL is supposed to be and what it is supposed to bring to the table.From what I've understood, it's basically a common banner for various different databases that all share the common property of not being relational databases and not providing ACID guarantees.If so, it seems to me that the whole NoSQL vs. RDMBS [wikipedia.org] debate is about a false dichotomy.
There are some applications where a relational database is the right tool for the job, and there are some where a relational database is not the right tool for the job.
In some of those latter cases, one of the NoSQL databases may be the right thing.This is nothing new.
Non-relational databases have been used on Unix for a long time, and are even a standard part of POSIX (see for example the manpage for dbm\_open [opengroup.org]).
It's also long been known that, for example, Berkeley DB [oracle.com] can be a lot faster than an RDBMS - as long as your application doesn't make use of all the features an RDBMS provides.
Lots of programs even don't use one of these database systems, but invent their own, custom format.
Git [git-scm.com] is a very successful example of this.To me, it seems that what we are seeing here is loads of people who had learned to use relational databases for all their storage needs discovering that there are other ways to store data, and that one of those methods may work better than an RDMBS for a particular application.
Well, yes.
Does that surprise anyone?
It sure doesn't surprise me.
Does it mean that RDMBSes are now useless?
Not at all.
Does it mean you should use a non-relational storage system where this makes more sense?
Of course!
Now, can we please get back to work?
I don't see the point of having a holy war over whether RDBMS or NoSQL is better, when common sense says that they both have their uses.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653908</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>SQL Error</author>
	<datestamp>1269804420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>So how do you make your system work with NoSQL? As you say in your post, "you lose ACID, indexes, and joins to varying degrees". To me, with my relational view of the world, it seems that you would want to use an RDBMS exactly because of these things. Specifically, the fact that your RDBMS does the hard work of keeping your data consistent for you.</p></div></blockquote><p>Sure, if your transactions are worth something.</p><p>In the world of social networking, consistency is much less important than speed.  If two different users see different data because the nodes are a few seconds out of sync, no-one cares.  But slow answers are <i>wrong</i> answers.</p><p>You can't do that with a bank or a stock exchange.  It would be a disaster.  For a social networking site, no-one will care - no-one will even notice.</p><blockquote><div><p>If so, what realistic expectation can you have to come up with something that is both correct and as performant as an RDBMS which lots of smart people have worked on over the years?</p></div></blockquote><p>We throw strict correctness out the window.  That's where most of the performance gain comes from.  You still have to build an architecture that can take advantage of this opportunity, though, and that's not trivial.</p><blockquote><div><p>Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES". Because I can build something that scales if it doesn't have to maintain ACID, too. The difficulty is in having \_both\_ ACID and scalability.</p></div></blockquote><p>Consistency, scalability, affordability.  Pick two...  At most.</p></div>
	</htmltext>
<tokenext>So how do you make your system work with NoSQL ?
As you say in your post , " you lose ACID , indexes , and joins to varying degrees " .
To me , with my relational view of the world , it seems that you would want to use an RDBMS exactly because of these things .
Specifically , the fact that your RDBMS does the hard work of keeping your data consistent for you.Sure , if your transactions are worth something.In the world of social networking , consistency is much less important than speed .
If two different users see different data because the nodes are a few seconds out of sync , no-one cares .
But slow answers are wrong answers.You ca n't do that with a bank or a stock exchange .
It would be a disaster .
For a social networking site , no-one will care - no-one will even notice.If so , what realistic expectation can you have to come up with something that is both correct and as performant as an RDBMS which lots of smart people have worked on over the years ? We throw strict correctness out the window .
That 's where most of the performance gain comes from .
You still have to build an architecture that can take advantage of this opportunity , though , and that 's not trivial.Or is it just that people are throwing consistency out of the window and saying " We can afford to lose a couple of records or have a couple of dangling references here and there , as long as it SCALES " .
Because I can build something that scales if it does n't have to maintain ACID , too .
The difficulty is in having \ _both \ _ ACID and scalability.Consistency , scalability , affordability .
Pick two... At most .</tokentext>
<sentencetext>So how do you make your system work with NoSQL?
As you say in your post, "you lose ACID, indexes, and joins to varying degrees".
To me, with my relational view of the world, it seems that you would want to use an RDBMS exactly because of these things.
Specifically, the fact that your RDBMS does the hard work of keeping your data consistent for you.Sure, if your transactions are worth something.In the world of social networking, consistency is much less important than speed.
If two different users see different data because the nodes are a few seconds out of sync, no-one cares.
But slow answers are wrong answers.You can't do that with a bank or a stock exchange.
It would be a disaster.
For a social networking site, no-one will care - no-one will even notice.If so, what realistic expectation can you have to come up with something that is both correct and as performant as an RDBMS which lots of smart people have worked on over the years?We throw strict correctness out the window.
That's where most of the performance gain comes from.
You still have to build an architecture that can take advantage of this opportunity, though, and that's not trivial.Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES".
Because I can build something that scales if it doesn't have to maintain ACID, too.
The difficulty is in having \_both\_ ACID and scalability.Consistency, scalability, affordability.
Pick two...  At most.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648306</id>
	<title>SQL performance</title>
	<author>Anonymous</author>
	<datestamp>1269799560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>People complaining about SQL performance are most likely either using incorrectly scaled machines for the job, or believe they can throw a four-line SQL statement at the database and expect it to work out the optimization on its own<nobr> <wbr></nobr>... query optimizers may be able to do a decent job on average, but once you go large databases (multi-million dataset tables), planing the query structure will go a long way preserving performance.<br>Yes one can write complicated queries to return exactly what you want in one query, but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query<nobr> <wbr></nobr>...</p></htmltext>
<tokenext>People complaining about SQL performance are most likely either using incorrectly scaled machines for the job , or believe they can throw a four-line SQL statement at the database and expect it to work out the optimization on its own ... query optimizers may be able to do a decent job on average , but once you go large databases ( multi-million dataset tables ) , planing the query structure will go a long way preserving performance.Yes one can write complicated queries to return exactly what you want in one query , but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query .. .</tokentext>
<sentencetext>People complaining about SQL performance are most likely either using incorrectly scaled machines for the job, or believe they can throw a four-line SQL statement at the database and expect it to work out the optimization on its own ... query optimizers may be able to do a decent job on average, but once you go large databases (multi-million dataset tables), planing the query structure will go a long way preserving performance.Yes one can write complicated queries to return exactly what you want in one query, but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query ...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31661186</id>
	<title>Re:More RDBMS dogma</title>
	<author>mdielmann</author>
	<datestamp>1269895140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>..."one size fits all" is always BS, even in clothing.</p></div><p>That dress seemed to work pretty well for Alice.  And if she had to do the shoot wearing a bikini so they could add the dress using CGI later, well, that works pretty well, too.<nobr> <wbr></nobr>;-)</p></div>
	</htmltext>
<tokenext>... " one size fits all " is always BS , even in clothing.That dress seemed to work pretty well for Alice .
And if she had to do the shoot wearing a bikini so they could add the dress using CGI later , well , that works pretty well , too .
; - )</tokentext>
<sentencetext> ..."one size fits all" is always BS, even in clothing.That dress seemed to work pretty well for Alice.
And if she had to do the shoot wearing a bikini so they could add the dress using CGI later, well, that works pretty well, too.
;-)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650180</id>
	<title>Re:Some people just want the holy grail</title>
	<author>BitZtream</author>
	<datestamp>1269770100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>I'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly.</p></div></blockquote><p>Depends on your goals.  If I were aiming for high reliability and performance, Assembly is the best way to go, but you'll be waiting years to get it done.</p><p>If I want it tomorrow in some way that works 50\% of the time or more, I'll use a 'modern' language.</p><p>The more 'modern' the language, the more complex it is in and of itself.  Anyone who truely understands how the GCs in the<nobr> <wbr></nobr>.NET runtime and Java work also know that they are extremely complex beasts and that 99.9\% of the people who use them don't have a clue as to what goes on behind the scenes.  This makes most modern languages in fact far more unsafe than lower level ones because while they make it easier at first glance, they are infact FAR more complex than what people think of as being 'hard'.</p><p>I've never had a problem with memory management in  assembly, but a basic webserver is the most I've ever had to write.  I don't think I've ever written a Java or<nobr> <wbr></nobr>.NET app that I haven't had circular reference issues preventing memory from getting collected or had some sort of cleanup performed on an object that was already tombstoned.</p><p>Your statement is exactly the problem with 'modern' langauges.  People assume they are easier but really don't understand how they work.</p><p>The problem is people think that throwing an exception box on the screen is somehow different than a crash with no warning other than 'it broke'.  The end result is the same, the program crashed.  It doesn't matter if the VM is able to provide some worthless message to the user, the user is still put out.  The only difference is the 'developer' (not that they should be called that) can say 'oh its a handled bug, don't do that' or some other bullshit they learned from MS.</p></div>
	</htmltext>
<tokenext>I 'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly.Depends on your goals .
If I were aiming for high reliability and performance , Assembly is the best way to go , but you 'll be waiting years to get it done.If I want it tomorrow in some way that works 50 \ % of the time or more , I 'll use a 'modern ' language.The more 'modern ' the language , the more complex it is in and of itself .
Anyone who truely understands how the GCs in the .NET runtime and Java work also know that they are extremely complex beasts and that 99.9 \ % of the people who use them do n't have a clue as to what goes on behind the scenes .
This makes most modern languages in fact far more unsafe than lower level ones because while they make it easier at first glance , they are infact FAR more complex than what people think of as being 'hard'.I 've never had a problem with memory management in assembly , but a basic webserver is the most I 've ever had to write .
I do n't think I 've ever written a Java or .NET app that I have n't had circular reference issues preventing memory from getting collected or had some sort of cleanup performed on an object that was already tombstoned.Your statement is exactly the problem with 'modern ' langauges .
People assume they are easier but really do n't understand how they work.The problem is people think that throwing an exception box on the screen is somehow different than a crash with no warning other than 'it broke' .
The end result is the same , the program crashed .
It does n't matter if the VM is able to provide some worthless message to the user , the user is still put out .
The only difference is the 'developer ' ( not that they should be called that ) can say 'oh its a handled bug , do n't do that ' or some other bullshit they learned from MS .</tokentext>
<sentencetext>I'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly.Depends on your goals.
If I were aiming for high reliability and performance, Assembly is the best way to go, but you'll be waiting years to get it done.If I want it tomorrow in some way that works 50\% of the time or more, I'll use a 'modern' language.The more 'modern' the language, the more complex it is in and of itself.
Anyone who truely understands how the GCs in the .NET runtime and Java work also know that they are extremely complex beasts and that 99.9\% of the people who use them don't have a clue as to what goes on behind the scenes.
This makes most modern languages in fact far more unsafe than lower level ones because while they make it easier at first glance, they are infact FAR more complex than what people think of as being 'hard'.I've never had a problem with memory management in  assembly, but a basic webserver is the most I've ever had to write.
I don't think I've ever written a Java or .NET app that I haven't had circular reference issues preventing memory from getting collected or had some sort of cleanup performed on an object that was already tombstoned.Your statement is exactly the problem with 'modern' langauges.
People assume they are easier but really don't understand how they work.The problem is people think that throwing an exception box on the screen is somehow different than a crash with no warning other than 'it broke'.
The end result is the same, the program crashed.
It doesn't matter if the VM is able to provide some worthless message to the user, the user is still put out.
The only difference is the 'developer' (not that they should be called that) can say 'oh its a handled bug, don't do that' or some other bullshit they learned from MS.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649554</id>
	<title>Use what is appropriate not FUD</title>
	<author>Joviex</author>
	<datestamp>1269808080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>It's a poor artist / programmer / cook / et. al.  that blames his tools.

If you know the problem, you use the best tool to solve it.

SQL or Document-DBs or Graph-DBs  whatever is the best fit to solve the problem is what you use.

You don't go around saying something is crap because you have no need for it.</htmltext>
<tokenext>It 's a poor artist / programmer / cook / et .
al. that blames his tools .
If you know the problem , you use the best tool to solve it .
SQL or Document-DBs or Graph-DBs whatever is the best fit to solve the problem is what you use .
You do n't go around saying something is crap because you have no need for it .</tokentext>
<sentencetext>It's a poor artist / programmer / cook / et.
al.  that blames his tools.
If you know the problem, you use the best tool to solve it.
SQL or Document-DBs or Graph-DBs  whatever is the best fit to solve the problem is what you use.
You don't go around saying something is crap because you have no need for it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647902</id>
	<title>Right Tools For The Job</title>
	<author>Ashcrow</author>
	<datestamp>1269796560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think the frustration is actually in some people not using the right tools for the job. I like NoSQL databases (specifically MongoDB), but I have not used them with anything I've written. Why? Because it wasn't the right tool for the job. I tend to use MySQL, Postgres or sqlite because it's so widely available and well known in how to administer. There are times that NoSQL will makes sense, it's just not the area I work in.
<br> <br>
I do think we are going to continue seeing an uptick in NoSQL related things since many companies are fixated on "the cloud" while not really knowing what "the cloud" is (heck, no one still really, truly has a common definition of what it means<nobr> <wbr></nobr>...). Since NoSQL seems to be a popular tool, and "the cloud" is a popular buzz phrase CIO's/CTO's will likely be pushing their shops to utilize "NoSQL in the cloud". While large scale applications which don't require relational information and need fast syncing across many servers is good grounds for NoSQL, these "NoSQL in the cloud" instances will probably not actually fit that status.
<br> <br>
I do agree that it will be a good thing when "NoSQL for everything" dies. Just like it was a good thing when "PERL for everything", "Java for everything" and "Ruby for everything" died, but let's not throw out the whole idea because a lot of people use it wrong.</htmltext>
<tokenext>I think the frustration is actually in some people not using the right tools for the job .
I like NoSQL databases ( specifically MongoDB ) , but I have not used them with anything I 've written .
Why ? Because it was n't the right tool for the job .
I tend to use MySQL , Postgres or sqlite because it 's so widely available and well known in how to administer .
There are times that NoSQL will makes sense , it 's just not the area I work in .
I do think we are going to continue seeing an uptick in NoSQL related things since many companies are fixated on " the cloud " while not really knowing what " the cloud " is ( heck , no one still really , truly has a common definition of what it means ... ) .
Since NoSQL seems to be a popular tool , and " the cloud " is a popular buzz phrase CIO 's/CTO 's will likely be pushing their shops to utilize " NoSQL in the cloud " .
While large scale applications which do n't require relational information and need fast syncing across many servers is good grounds for NoSQL , these " NoSQL in the cloud " instances will probably not actually fit that status .
I do agree that it will be a good thing when " NoSQL for everything " dies .
Just like it was a good thing when " PERL for everything " , " Java for everything " and " Ruby for everything " died , but let 's not throw out the whole idea because a lot of people use it wrong .</tokentext>
<sentencetext>I think the frustration is actually in some people not using the right tools for the job.
I like NoSQL databases (specifically MongoDB), but I have not used them with anything I've written.
Why? Because it wasn't the right tool for the job.
I tend to use MySQL, Postgres or sqlite because it's so widely available and well known in how to administer.
There are times that NoSQL will makes sense, it's just not the area I work in.
I do think we are going to continue seeing an uptick in NoSQL related things since many companies are fixated on "the cloud" while not really knowing what "the cloud" is (heck, no one still really, truly has a common definition of what it means ...).
Since NoSQL seems to be a popular tool, and "the cloud" is a popular buzz phrase CIO's/CTO's will likely be pushing their shops to utilize "NoSQL in the cloud".
While large scale applications which don't require relational information and need fast syncing across many servers is good grounds for NoSQL, these "NoSQL in the cloud" instances will probably not actually fit that status.
I do agree that it will be a good thing when "NoSQL for everything" dies.
Just like it was a good thing when "PERL for everything", "Java for everything" and "Ruby for everything" died, but let's not throw out the whole idea because a lot of people use it wrong.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650302</id>
	<title>Re:More RDBMS dogma</title>
	<author>Jane Q. Public</author>
	<datestamp>1269770820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Agree with the other poster. Medical records would seem to be an ideal candidate for relational mapping. Not all the information of course, there is plenty of room for free-form text. But that fits into the relational model, too.
<br> <br>
Certainly, some things would be huge. The sheer number of possible maladies, for example. Nevertheless, that is not an argument for non-relational storage. And files... relational DBs handle digital images (high-res scans of x-ray film, for example) just fine. If performance is an issue, it is not necessary to store the binary information in the database itself. And the location of the original physical files can be tracked easily.
<br> <br>
So unless there is something I simply haven't considered, I have no idea why medical records might be unsuited for a relational model.</htmltext>
<tokenext>Agree with the other poster .
Medical records would seem to be an ideal candidate for relational mapping .
Not all the information of course , there is plenty of room for free-form text .
But that fits into the relational model , too .
Certainly , some things would be huge .
The sheer number of possible maladies , for example .
Nevertheless , that is not an argument for non-relational storage .
And files... relational DBs handle digital images ( high-res scans of x-ray film , for example ) just fine .
If performance is an issue , it is not necessary to store the binary information in the database itself .
And the location of the original physical files can be tracked easily .
So unless there is something I simply have n't considered , I have no idea why medical records might be unsuited for a relational model .</tokentext>
<sentencetext>Agree with the other poster.
Medical records would seem to be an ideal candidate for relational mapping.
Not all the information of course, there is plenty of room for free-form text.
But that fits into the relational model, too.
Certainly, some things would be huge.
The sheer number of possible maladies, for example.
Nevertheless, that is not an argument for non-relational storage.
And files... relational DBs handle digital images (high-res scans of x-ray film, for example) just fine.
If performance is an issue, it is not necessary to store the binary information in the database itself.
And the location of the original physical files can be tracked easily.
So unless there is something I simply haven't considered, I have no idea why medical records might be unsuited for a relational model.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648120</id>
	<title>"It's Just a damned popularity with you kids!"</title>
	<author>Dark\_Matter88</author>
	<datestamp>1269798060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sure, Ive messed around with some NoSQL databases, they just aren't my thing, give me mysql, your spec and a cup of tea and i dont have to look round silly experiments to see the best way of doing things in new radical 'paradigms.' That being said, I am glad the experiments are being done by people who are in such an environment to experiment. I mean, like the article says, its the social networks like twitter and facebook developing things like Cassandra, and its good that there is someone pushing the bar, but they are the only people who CAN do this, they aren't necessary, nobodies gonna die from a 5 minute outtage of poking each other (that sounds bad). I havent really understood the whole NoSQL thing,I havent really ever had a problem with SQL based Databases, maybe thats just the nature of my work, but it all seems as though this has nothing to do with technology, just people who want to be heard...</htmltext>
<tokenext>Sure , Ive messed around with some NoSQL databases , they just are n't my thing , give me mysql , your spec and a cup of tea and i dont have to look round silly experiments to see the best way of doing things in new radical 'paradigms .
' That being said , I am glad the experiments are being done by people who are in such an environment to experiment .
I mean , like the article says , its the social networks like twitter and facebook developing things like Cassandra , and its good that there is someone pushing the bar , but they are the only people who CAN do this , they are n't necessary , nobodies gon na die from a 5 minute outtage of poking each other ( that sounds bad ) .
I havent really understood the whole NoSQL thing,I havent really ever had a problem with SQL based Databases , maybe thats just the nature of my work , but it all seems as though this has nothing to do with technology , just people who want to be heard.. .</tokentext>
<sentencetext>Sure, Ive messed around with some NoSQL databases, they just aren't my thing, give me mysql, your spec and a cup of tea and i dont have to look round silly experiments to see the best way of doing things in new radical 'paradigms.
' That being said, I am glad the experiments are being done by people who are in such an environment to experiment.
I mean, like the article says, its the social networks like twitter and facebook developing things like Cassandra, and its good that there is someone pushing the bar, but they are the only people who CAN do this, they aren't necessary, nobodies gonna die from a 5 minute outtage of poking each other (that sounds bad).
I havent really understood the whole NoSQL thing,I havent really ever had a problem with SQL based Databases, maybe thats just the nature of my work, but it all seems as though this has nothing to do with technology, just people who want to be heard...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652316</id>
	<title>Re:Price may favor noSQL for some applications</title>
	<author>Anonymous</author>
	<datestamp>1269787020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you're not big enough to pay for Oracle, you're not big enough to need the scalability anyhow. There are probably only dozens of sites that actually need NoSQL solutions for scalability. Of course there are other reasons to use hierarchical key-value stores, and you have at least one on each of your computers -- it's called a filesystem. Nobody's going to argue that relational is the only way to store data (well, Oracle might argue that), but it's foolish to try to use a non-relational DB for data that relational DBs are best at.</p><p>dom</p></htmltext>
<tokenext>If you 're not big enough to pay for Oracle , you 're not big enough to need the scalability anyhow .
There are probably only dozens of sites that actually need NoSQL solutions for scalability .
Of course there are other reasons to use hierarchical key-value stores , and you have at least one on each of your computers -- it 's called a filesystem .
Nobody 's going to argue that relational is the only way to store data ( well , Oracle might argue that ) , but it 's foolish to try to use a non-relational DB for data that relational DBs are best at.dom</tokentext>
<sentencetext>If you're not big enough to pay for Oracle, you're not big enough to need the scalability anyhow.
There are probably only dozens of sites that actually need NoSQL solutions for scalability.
Of course there are other reasons to use hierarchical key-value stores, and you have at least one on each of your computers -- it's called a filesystem.
Nobody's going to argue that relational is the only way to store data (well, Oracle might argue that), but it's foolish to try to use a non-relational DB for data that relational DBs are best at.dom</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648134</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269803220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So you're saying that an RDBMS is the right tool for the job if your transactions have enough value, and, if the value per transaction is too low, you won't be able to afford an RDBMS, but you can still go with a NoSQL database? That's an interesting point of view.</p><p>So how do you make your system work with NoSQL? As you say in your post, "you lose ACID, indexes, and joins to varying degrees". To me, with my relational view of the world, it seems that you would want to use an RDBMS exactly because of these things. Specifically, the fact that your RDBMS does the hard work of keeping your data consistent for you. Wouldn't you have to implement that all by yourself if you went with a NoSQL system? If so, what realistic expectation can you have to come up with something that is both correct and as performant as an RDBMS which lots of smart people have worked on over the years?</p><p>Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES". Because I can build something that scales if it doesn't have to maintain ACID, too. The difficulty is in having \_both\_ ACID and scalability.</p></htmltext>
<tokenext>So you 're saying that an RDBMS is the right tool for the job if your transactions have enough value , and , if the value per transaction is too low , you wo n't be able to afford an RDBMS , but you can still go with a NoSQL database ?
That 's an interesting point of view.So how do you make your system work with NoSQL ?
As you say in your post , " you lose ACID , indexes , and joins to varying degrees " .
To me , with my relational view of the world , it seems that you would want to use an RDBMS exactly because of these things .
Specifically , the fact that your RDBMS does the hard work of keeping your data consistent for you .
Would n't you have to implement that all by yourself if you went with a NoSQL system ?
If so , what realistic expectation can you have to come up with something that is both correct and as performant as an RDBMS which lots of smart people have worked on over the years ? Or is it just that people are throwing consistency out of the window and saying " We can afford to lose a couple of records or have a couple of dangling references here and there , as long as it SCALES " .
Because I can build something that scales if it does n't have to maintain ACID , too .
The difficulty is in having \ _both \ _ ACID and scalability .</tokentext>
<sentencetext>So you're saying that an RDBMS is the right tool for the job if your transactions have enough value, and, if the value per transaction is too low, you won't be able to afford an RDBMS, but you can still go with a NoSQL database?
That's an interesting point of view.So how do you make your system work with NoSQL?
As you say in your post, "you lose ACID, indexes, and joins to varying degrees".
To me, with my relational view of the world, it seems that you would want to use an RDBMS exactly because of these things.
Specifically, the fact that your RDBMS does the hard work of keeping your data consistent for you.
Wouldn't you have to implement that all by yourself if you went with a NoSQL system?
If so, what realistic expectation can you have to come up with something that is both correct and as performant as an RDBMS which lots of smart people have worked on over the years?Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES".
Because I can build something that scales if it doesn't have to maintain ACID, too.
The difficulty is in having \_both\_ ACID and scalability.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647940</id>
	<title>because all apps are the same</title>
	<author>vonkohorn</author>
	<datestamp>1269796860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So they should all use the same data management tools as wallmart.  Is that the reasoning?

Better to use the right tool for each job.  Some things work better in a nosql non-schema.</htmltext>
<tokenext>So they should all use the same data management tools as wallmart .
Is that the reasoning ?
Better to use the right tool for each job .
Some things work better in a nosql non-schema .</tokentext>
<sentencetext>So they should all use the same data management tools as wallmart.
Is that the reasoning?
Better to use the right tool for each job.
Some things work better in a nosql non-schema.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31657572</id>
	<title>Interesting...</title>
	<author>Anonymous</author>
	<datestamp>1269879240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>NoSQL should be posted on The Daily WTF....</p></htmltext>
<tokenext>NoSQL should be posted on The Daily WTF... .</tokentext>
<sentencetext>NoSQL should be posted on The Daily WTF....</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648436</id>
	<title>Walmart's primary business isn't online: REALLY?</title>
	<author>lenski</author>
	<datestamp>1269800460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I thought it was reasonably well understood that one of Walmart's primary characteristics is their *amazing* control over logistics. In fact, I thought one of their big process inventions was to bring logistical activity online.</p><p>I welcome clarification, since I haven't worked for Walmart.</p></htmltext>
<tokenext>I thought it was reasonably well understood that one of Walmart 's primary characteristics is their * amazing * control over logistics .
In fact , I thought one of their big process inventions was to bring logistical activity online.I welcome clarification , since I have n't worked for Walmart .</tokentext>
<sentencetext>I thought it was reasonably well understood that one of Walmart's primary characteristics is their *amazing* control over logistics.
In fact, I thought one of their big process inventions was to bring logistical activity online.I welcome clarification, since I haven't worked for Walmart.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647896</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649796</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269766800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Comparing walmart to facebook is silly too.  The basic requirement is different.  With walmart EVERY transaction must be perfect but it doesnt need to be distributed to 800 people who are looking at different views of the pages.  Facebook on the other hand doesnt have to be perfectly consistent.  If users 600-800 dont quite get the same view as the first 600 thats ok.  They will get the right view in 10-15 minutes.</p><p>Facebook is trading C from ACID for speed.  The dude running the report at Walmart doesnt care if it takes 2 hours to run the report.  He wants it to be correct.  The dude opening some page on Facebook doesnt care if it doesnt show every last detail just that his page opens quickly and 99\% of the data is mostly right.</p><p>The problem people are having with 'SQL' is the 'big table' problem where all the other tables in the system are fairly static but you have 1 or 2 HUGE tables that everyone uses.  But when it comes down to it that 'big table' doesnt really have to be a table at all.  It could be something else.  IF you are willing to sacrifice different parts of ACID for it.</p><p>I see this issue all the time with other aspects of programs.  Either pre optimizing things or waiting until it is totally screwed up THEN trying to fix it.  You need to test early to find out where your constraints are then as you approach them start pulling parts out and optimizing those.  Do it to early and you can really mess things up do it to late and your screwed.  But if you know about where the wheels are going to fly off you can prep for it.  Then if you never get near the flying off stage you do not have to devote time and money to fixing something that is never going to happen.</p></htmltext>
<tokenext>Comparing walmart to facebook is silly too .
The basic requirement is different .
With walmart EVERY transaction must be perfect but it doesnt need to be distributed to 800 people who are looking at different views of the pages .
Facebook on the other hand doesnt have to be perfectly consistent .
If users 600-800 dont quite get the same view as the first 600 thats ok. They will get the right view in 10-15 minutes.Facebook is trading C from ACID for speed .
The dude running the report at Walmart doesnt care if it takes 2 hours to run the report .
He wants it to be correct .
The dude opening some page on Facebook doesnt care if it doesnt show every last detail just that his page opens quickly and 99 \ % of the data is mostly right.The problem people are having with 'SQL ' is the 'big table ' problem where all the other tables in the system are fairly static but you have 1 or 2 HUGE tables that everyone uses .
But when it comes down to it that 'big table ' doesnt really have to be a table at all .
It could be something else .
IF you are willing to sacrifice different parts of ACID for it.I see this issue all the time with other aspects of programs .
Either pre optimizing things or waiting until it is totally screwed up THEN trying to fix it .
You need to test early to find out where your constraints are then as you approach them start pulling parts out and optimizing those .
Do it to early and you can really mess things up do it to late and your screwed .
But if you know about where the wheels are going to fly off you can prep for it .
Then if you never get near the flying off stage you do not have to devote time and money to fixing something that is never going to happen .</tokentext>
<sentencetext>Comparing walmart to facebook is silly too.
The basic requirement is different.
With walmart EVERY transaction must be perfect but it doesnt need to be distributed to 800 people who are looking at different views of the pages.
Facebook on the other hand doesnt have to be perfectly consistent.
If users 600-800 dont quite get the same view as the first 600 thats ok.  They will get the right view in 10-15 minutes.Facebook is trading C from ACID for speed.
The dude running the report at Walmart doesnt care if it takes 2 hours to run the report.
He wants it to be correct.
The dude opening some page on Facebook doesnt care if it doesnt show every last detail just that his page opens quickly and 99\% of the data is mostly right.The problem people are having with 'SQL' is the 'big table' problem where all the other tables in the system are fairly static but you have 1 or 2 HUGE tables that everyone uses.
But when it comes down to it that 'big table' doesnt really have to be a table at all.
It could be something else.
IF you are willing to sacrifice different parts of ACID for it.I see this issue all the time with other aspects of programs.
Either pre optimizing things or waiting until it is totally screwed up THEN trying to fix it.
You need to test early to find out where your constraints are then as you approach them start pulling parts out and optimizing those.
Do it to early and you can really mess things up do it to late and your screwed.
But if you know about where the wheels are going to fly off you can prep for it.
Then if you never get near the flying off stage you do not have to devote time and money to fixing something that is never going to happen.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652148</id>
	<title>Re:SQL performance</title>
	<author>Just Some Guy</author>
	<datestamp>1269785580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>query optimizers may be able to do a decent job on average, but once you go large databases (multi-million dataset tables), planing the query structure will go a long way preserving performance.
Yes one can write complicated queries to return exactly what you want in one query, but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query<nobr> <wbr></nobr>...</p></div><p>No offense, but are you primarily used to MySQL? My company's PostgreSQL tables are (I think) pretty small, on the order of a few tens of millions of rows in the larger ones. They're small enough that I've never bothered with setting up partitioning; each table really is just a big ol' table. Still, they're big enough to benefit from approaching them intelligently. In every case when smart goruping and loops were running too slow, I found that replacing the client-side mess with a few complex queries fixed the problem. In short, its query analyzer is far better at optimization than we are, on average. A database is exceedingly good at managing data. Why not let it?</p></div>
	</htmltext>
<tokenext>query optimizers may be able to do a decent job on average , but once you go large databases ( multi-million dataset tables ) , planing the query structure will go a long way preserving performance .
Yes one can write complicated queries to return exactly what you want in one query , but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query ...No offense , but are you primarily used to MySQL ?
My company 's PostgreSQL tables are ( I think ) pretty small , on the order of a few tens of millions of rows in the larger ones .
They 're small enough that I 've never bothered with setting up partitioning ; each table really is just a big ol ' table .
Still , they 're big enough to benefit from approaching them intelligently .
In every case when smart goruping and loops were running too slow , I found that replacing the client-side mess with a few complex queries fixed the problem .
In short , its query analyzer is far better at optimization than we are , on average .
A database is exceedingly good at managing data .
Why not let it ?</tokentext>
<sentencetext>query optimizers may be able to do a decent job on average, but once you go large databases (multi-million dataset tables), planing the query structure will go a long way preserving performance.
Yes one can write complicated queries to return exactly what you want in one query, but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query ...No offense, but are you primarily used to MySQL?
My company's PostgreSQL tables are (I think) pretty small, on the order of a few tens of millions of rows in the larger ones.
They're small enough that I've never bothered with setting up partitioning; each table really is just a big ol' table.
Still, they're big enough to benefit from approaching them intelligently.
In every case when smart goruping and loops were running too slow, I found that replacing the client-side mess with a few complex queries fixed the problem.
In short, its query analyzer is far better at optimization than we are, on average.
A database is exceedingly good at managing data.
Why not let it?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648306</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648372</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Front Line Assembly</author>
	<datestamp>1269799920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It should probably be called NoMysql instead of NoSQL...</p><p>Here are some good posts. Seems NoSQL is just the new xml. Sure, great for some things, but not really worth the hype...</p><p><a href="http://www.yafla.com/dforbes/Responding\_to\_Joe\_Stump\_on\_the\_NoSQL\_Debate/" title="yafla.com" rel="nofollow">http://www.yafla.com/dforbes/Responding\_to\_Joe\_Stump\_on\_the\_NoSQL\_Debate/</a> [yafla.com]<br><a href="http://www.yafla.com/dforbes/Getting\_Real\_about\_NoSQL\_and\_the\_SQL\_Isnt\_Scalable\_Lie/" title="yafla.com" rel="nofollow">http://www.yafla.com/dforbes/Getting\_Real\_about\_NoSQL\_and\_the\_SQL\_Isnt\_Scalable\_Lie/</a> [yafla.com]<br><a href="http://www.yafla.com/dforbes/Getting\_Real\_about\_NoSQL\_and\_the\_SQL\_Performance\_Lie/" title="yafla.com" rel="nofollow">http://www.yafla.com/dforbes/Getting\_Real\_about\_NoSQL\_and\_the\_SQL\_Performance\_Lie/</a> [yafla.com]</p></htmltext>
<tokenext>It should probably be called NoMysql instead of NoSQL...Here are some good posts .
Seems NoSQL is just the new xml .
Sure , great for some things , but not really worth the hype...http : //www.yafla.com/dforbes/Responding \ _to \ _Joe \ _Stump \ _on \ _the \ _NoSQL \ _Debate/ [ yafla.com ] http : //www.yafla.com/dforbes/Getting \ _Real \ _about \ _NoSQL \ _and \ _the \ _SQL \ _Isnt \ _Scalable \ _Lie/ [ yafla.com ] http : //www.yafla.com/dforbes/Getting \ _Real \ _about \ _NoSQL \ _and \ _the \ _SQL \ _Performance \ _Lie/ [ yafla.com ]</tokentext>
<sentencetext>It should probably be called NoMysql instead of NoSQL...Here are some good posts.
Seems NoSQL is just the new xml.
Sure, great for some things, but not really worth the hype...http://www.yafla.com/dforbes/Responding\_to\_Joe\_Stump\_on\_the\_NoSQL\_Debate/ [yafla.com]http://www.yafla.com/dforbes/Getting\_Real\_about\_NoSQL\_and\_the\_SQL\_Isnt\_Scalable\_Lie/ [yafla.com]http://www.yafla.com/dforbes/Getting\_Real\_about\_NoSQL\_and\_the\_SQL\_Performance\_Lie/ [yafla.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648304</id>
	<title>Re:Some people just want the holy grail</title>
	<author>SanityInAnarchy</author>
	<datestamp>1269799500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I think some developers keep looking for the holy grail. Some magical solution that will turn development from punching in code, to Star Trek: "Computer do my job for me please".</p></div><p>While true, that doesn't invalidate actual progress.</p><p><div class="quote"><p>deep down, with all the frameworks and generators, if you want your code to do what you want it to do, you are still writing out if statements a lot.</p></div><p>Sure, no one claimed otherwise. The point is that I'd much rather be writing the if statements that have something to do with what I want my code to do, rather than the if statements that have to do with how to manage a session, or how to handle one URL vs another, or how to sanitize this particular query for the database.</p><p>As an example, you bash Rails -- ActiveRecord is hardly the only ORM capable of this, but it's possible to build a Rails app without writing a single line of SQL, or opening yourself up to a hint of a possibility of a SQL injection attack. Similarly, writing in any language higher-level than, say, C or C++, will generally save you from the possibility of a buffer overrun.</p><p>Now, is that going to take out <i>all</i> the tedium? No, it might not even make my job less tedious at all. What it will do is mean I'm <i>more productive</i> -- I'm doing more in the same amount of time. That's usually valuable.</p><p><div class="quote"><p>yes, OO and such also belong to this. Not the concept themselves, but the way most people talk about. OO means code re-use right?</p></div><p>It's a way of organizing your program, and it actually does have a lot to do with code re-use. For example:</p><p><div class="quote"><p>Apparently you can't re-use functions. No way, no how. NEXT!</p></div><p>One core goal of OO is to encapsulate and hide away the details of a given concept and expose only a simple, re-usable interface. Now, anything you can do in one Turing-complete language, you can do in another, but it can be a considerably different level of pain and complexity. Consider basic patterns like iterators in a language like C -- yes, you can do them, but does it really make sense?</p><p><div class="quote"><p>Just check, how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you don't need to write another line of code ever!</p></div><p>Well, I tend to advocate Rails, web apps, NoSQL, REST, higher-level languages, metaprogramming, and so on. I do this partly because of what I can do with those, and partly because they make my job easier, and thus more productive.</p><p>I never do them because I expect to stop having to write code.</p></div>
	</htmltext>
<tokenext>I think some developers keep looking for the holy grail .
Some magical solution that will turn development from punching in code , to Star Trek : " Computer do my job for me please " .While true , that does n't invalidate actual progress.deep down , with all the frameworks and generators , if you want your code to do what you want it to do , you are still writing out if statements a lot.Sure , no one claimed otherwise .
The point is that I 'd much rather be writing the if statements that have something to do with what I want my code to do , rather than the if statements that have to do with how to manage a session , or how to handle one URL vs another , or how to sanitize this particular query for the database.As an example , you bash Rails -- ActiveRecord is hardly the only ORM capable of this , but it 's possible to build a Rails app without writing a single line of SQL , or opening yourself up to a hint of a possibility of a SQL injection attack .
Similarly , writing in any language higher-level than , say , C or C + + , will generally save you from the possibility of a buffer overrun.Now , is that going to take out all the tedium ?
No , it might not even make my job less tedious at all .
What it will do is mean I 'm more productive -- I 'm doing more in the same amount of time .
That 's usually valuable.yes , OO and such also belong to this .
Not the concept themselves , but the way most people talk about .
OO means code re-use right ? It 's a way of organizing your program , and it actually does have a lot to do with code re-use .
For example : Apparently you ca n't re-use functions .
No way , no how .
NEXT ! One core goal of OO is to encapsulate and hide away the details of a given concept and expose only a simple , re-usable interface .
Now , anything you can do in one Turing-complete language , you can do in another , but it can be a considerably different level of pain and complexity .
Consider basic patterns like iterators in a language like C -- yes , you can do them , but does it really make sense ? Just check , how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you do n't need to write another line of code ever ! Well , I tend to advocate Rails , web apps , NoSQL , REST , higher-level languages , metaprogramming , and so on .
I do this partly because of what I can do with those , and partly because they make my job easier , and thus more productive.I never do them because I expect to stop having to write code .</tokentext>
<sentencetext>I think some developers keep looking for the holy grail.
Some magical solution that will turn development from punching in code, to Star Trek: "Computer do my job for me please".While true, that doesn't invalidate actual progress.deep down, with all the frameworks and generators, if you want your code to do what you want it to do, you are still writing out if statements a lot.Sure, no one claimed otherwise.
The point is that I'd much rather be writing the if statements that have something to do with what I want my code to do, rather than the if statements that have to do with how to manage a session, or how to handle one URL vs another, or how to sanitize this particular query for the database.As an example, you bash Rails -- ActiveRecord is hardly the only ORM capable of this, but it's possible to build a Rails app without writing a single line of SQL, or opening yourself up to a hint of a possibility of a SQL injection attack.
Similarly, writing in any language higher-level than, say, C or C++, will generally save you from the possibility of a buffer overrun.Now, is that going to take out all the tedium?
No, it might not even make my job less tedious at all.
What it will do is mean I'm more productive -- I'm doing more in the same amount of time.
That's usually valuable.yes, OO and such also belong to this.
Not the concept themselves, but the way most people talk about.
OO means code re-use right?It's a way of organizing your program, and it actually does have a lot to do with code re-use.
For example:Apparently you can't re-use functions.
No way, no how.
NEXT!One core goal of OO is to encapsulate and hide away the details of a given concept and expose only a simple, re-usable interface.
Now, anything you can do in one Turing-complete language, you can do in another, but it can be a considerably different level of pain and complexity.
Consider basic patterns like iterators in a language like C -- yes, you can do them, but does it really make sense?Just check, how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you don't need to write another line of code ever!Well, I tend to advocate Rails, web apps, NoSQL, REST, higher-level languages, metaprogramming, and so on.
I do this partly because of what I can do with those, and partly because they make my job easier, and thus more productive.I never do them because I expect to stop having to write code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647550</id>
	<title>Article summary</title>
	<author>Anonymous</author>
	<datestamp>1269793860000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>People who don't like SQL should get their heads out of their asses and use MySQL, a robust and enterprise-ready database.</p><p>Interesting thesis...</p></htmltext>
<tokenext>People who do n't like SQL should get their heads out of their asses and use MySQL , a robust and enterprise-ready database.Interesting thesis.. .</tokentext>
<sentencetext>People who don't like SQL should get their heads out of their asses and use MySQL, a robust and enterprise-ready database.Interesting thesis...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648294</id>
	<title>BS</title>
	<author>ajung</author>
	<datestamp>1269799500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I call: bullshit</p><p>We are using object-oriented databases like the ZODB for ten years when the data model is not relational oriented<br>We are using relational databases when your data is relational<br>We are using relational databases and object-oriented databases together in the same app when we need both<br>We are not using MySQL when we are in need of a *real* database.</p><p>Use the right tool for each problem - only idiots use a RDBMS for all and everything.</p></htmltext>
<tokenext>I call : bullshitWe are using object-oriented databases like the ZODB for ten years when the data model is not relational orientedWe are using relational databases when your data is relationalWe are using relational databases and object-oriented databases together in the same app when we need bothWe are not using MySQL when we are in need of a * real * database.Use the right tool for each problem - only idiots use a RDBMS for all and everything .</tokentext>
<sentencetext>I call: bullshitWe are using object-oriented databases like the ZODB for ten years when the data model is not relational orientedWe are using relational databases when your data is relationalWe are using relational databases and object-oriented databases together in the same app when we need bothWe are not using MySQL when we are in need of a *real* database.Use the right tool for each problem - only idiots use a RDBMS for all and everything.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650570</id>
	<title>We need alternatives to SQL.</title>
	<author>codealot</author>
	<datestamp>1269772740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As another poster pointed out, this is a false dichotomy.  We're emerging from a technology monoculture of "every DBMS must be SQL" to "it's possible, even viable to design, implement and use a DBMS that does not implement SQL".  Anyone advocating a mass exodus from SQL-land is a fool.  Props to the NoSQL guys for opening our eyes to fresh ideas.</p><p>There's no need to stick with any single DBMS platform for 100\% of your organization, unless you're so small that you have but one server total, and then I suspect this debate is largely irrelevant to you anyhow.</p><p>We're not Google, but we have some of the same problems Google faced with scaling up our applications for the Internet.  We do use MySQL, having some 35+ instances of it.  Our application processes in excess of 1000 transactions each second, and we know it'll be difficult to scale to tens of thousands of transactions per second without some fundamental changes.  Today we survive by imposing limitations on developers writing OLTP applications--things like "all row operations must search by primary key" and "no table scans, ad-hoc queries or file sorts".  The access language is still SQL, but increasingly we don't *need* SQL for OLTP transactions.  We could plug in something today that is equivalent and far simpler.</p><p>What we're lacking in SQL-land is a good way to host DBMS applications on distributed infrastructure, e.g. in the cloud.  There are clustered databases available, but these often require fast/short interconnects, may have difficulty scaling above bandwidth limits on a local network or SAN, and can be frustratingly fragile to use in the "real world".  Not to mention expensive.  This is due to the consistency model imposed on such systems, i.e. the "AC" in ACID.</p><p>Data sharding is a popular way to exceed the limits of SQL, but once you introduce sharding you're treading on "NoSQL" waters already.  You can't retrofit sharding onto an application that isn't aware of it, not very successfully, in my experience.  So developers need to become acutely aware of the storage tier and design for it, meaning they've already lost the perfect abstraction of SQL.</p><p>I'm keenly interested in emerging products like the Cassandra database, and while I have no intent of ever abandoning SQL (and probably even MySQL) in our organization, we're absolutely going to take "NoSQL" for a spin to see what it delivers in terms of cost, complexity, relability and performance.</p></htmltext>
<tokenext>As another poster pointed out , this is a false dichotomy .
We 're emerging from a technology monoculture of " every DBMS must be SQL " to " it 's possible , even viable to design , implement and use a DBMS that does not implement SQL " .
Anyone advocating a mass exodus from SQL-land is a fool .
Props to the NoSQL guys for opening our eyes to fresh ideas.There 's no need to stick with any single DBMS platform for 100 \ % of your organization , unless you 're so small that you have but one server total , and then I suspect this debate is largely irrelevant to you anyhow.We 're not Google , but we have some of the same problems Google faced with scaling up our applications for the Internet .
We do use MySQL , having some 35 + instances of it .
Our application processes in excess of 1000 transactions each second , and we know it 'll be difficult to scale to tens of thousands of transactions per second without some fundamental changes .
Today we survive by imposing limitations on developers writing OLTP applications--things like " all row operations must search by primary key " and " no table scans , ad-hoc queries or file sorts " .
The access language is still SQL , but increasingly we do n't * need * SQL for OLTP transactions .
We could plug in something today that is equivalent and far simpler.What we 're lacking in SQL-land is a good way to host DBMS applications on distributed infrastructure , e.g .
in the cloud .
There are clustered databases available , but these often require fast/short interconnects , may have difficulty scaling above bandwidth limits on a local network or SAN , and can be frustratingly fragile to use in the " real world " .
Not to mention expensive .
This is due to the consistency model imposed on such systems , i.e .
the " AC " in ACID.Data sharding is a popular way to exceed the limits of SQL , but once you introduce sharding you 're treading on " NoSQL " waters already .
You ca n't retrofit sharding onto an application that is n't aware of it , not very successfully , in my experience .
So developers need to become acutely aware of the storage tier and design for it , meaning they 've already lost the perfect abstraction of SQL.I 'm keenly interested in emerging products like the Cassandra database , and while I have no intent of ever abandoning SQL ( and probably even MySQL ) in our organization , we 're absolutely going to take " NoSQL " for a spin to see what it delivers in terms of cost , complexity , relability and performance .</tokentext>
<sentencetext>As another poster pointed out, this is a false dichotomy.
We're emerging from a technology monoculture of "every DBMS must be SQL" to "it's possible, even viable to design, implement and use a DBMS that does not implement SQL".
Anyone advocating a mass exodus from SQL-land is a fool.
Props to the NoSQL guys for opening our eyes to fresh ideas.There's no need to stick with any single DBMS platform for 100\% of your organization, unless you're so small that you have but one server total, and then I suspect this debate is largely irrelevant to you anyhow.We're not Google, but we have some of the same problems Google faced with scaling up our applications for the Internet.
We do use MySQL, having some 35+ instances of it.
Our application processes in excess of 1000 transactions each second, and we know it'll be difficult to scale to tens of thousands of transactions per second without some fundamental changes.
Today we survive by imposing limitations on developers writing OLTP applications--things like "all row operations must search by primary key" and "no table scans, ad-hoc queries or file sorts".
The access language is still SQL, but increasingly we don't *need* SQL for OLTP transactions.
We could plug in something today that is equivalent and far simpler.What we're lacking in SQL-land is a good way to host DBMS applications on distributed infrastructure, e.g.
in the cloud.
There are clustered databases available, but these often require fast/short interconnects, may have difficulty scaling above bandwidth limits on a local network or SAN, and can be frustratingly fragile to use in the "real world".
Not to mention expensive.
This is due to the consistency model imposed on such systems, i.e.
the "AC" in ACID.Data sharding is a popular way to exceed the limits of SQL, but once you introduce sharding you're treading on "NoSQL" waters already.
You can't retrofit sharding onto an application that isn't aware of it, not very successfully, in my experience.
So developers need to become acutely aware of the storage tier and design for it, meaning they've already lost the perfect abstraction of SQL.I'm keenly interested in emerging products like the Cassandra database, and while I have no intent of ever abandoning SQL (and probably even MySQL) in our organization, we're absolutely going to take "NoSQL" for a spin to see what it delivers in terms of cost, complexity, relability and performance.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648326</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269799680000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've got news for you<nobr> <wbr></nobr>... all the major stock exchanges, banks, and telecoms in the world use SQL RDBMSs to track transactions that match or exceed anything Facebook and Twitter are doing. I guarantee you, without a single doubt in my mind, that Facebook and Twitter could be run on a SQL RDBMS<nobr> <wbr></nobr>... by that I mean Oracle, not MySQL.</p></htmltext>
<tokenext>I 've got news for you ... all the major stock exchanges , banks , and telecoms in the world use SQL RDBMSs to track transactions that match or exceed anything Facebook and Twitter are doing .
I guarantee you , without a single doubt in my mind , that Facebook and Twitter could be run on a SQL RDBMS ... by that I mean Oracle , not MySQL .</tokentext>
<sentencetext>I've got news for you ... all the major stock exchanges, banks, and telecoms in the world use SQL RDBMSs to track transactions that match or exceed anything Facebook and Twitter are doing.
I guarantee you, without a single doubt in my mind, that Facebook and Twitter could be run on a SQL RDBMS ... by that I mean Oracle, not MySQL.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31665862</id>
	<title>Mongo</title>
	<author>GWBasic</author>
	<datestamp>1269877740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've been pretty happy with MongoDB.  Why?  The document architecture makes ORM a lot easier.</htmltext>
<tokenext>I 've been pretty happy with MongoDB .
Why ? The document architecture makes ORM a lot easier .</tokentext>
<sentencetext>I've been pretty happy with MongoDB.
Why?  The document architecture makes ORM a lot easier.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648724</id>
	<title>WalMart doesn't use SQL</title>
	<author>Anonymous</author>
	<datestamp>1269802320000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>WalMart has one of the largest <a href="http://www.eweek.com/c/a/Enterprise-Applications/At-WalMart-Worlds-Largest-Retail-Data-Warehouse-Gets-Even-Larger/" title="eweek.com" rel="nofollow">Teradata installs</a> [eweek.com], it doesn't use SQL.</p></htmltext>
<tokenext>WalMart has one of the largest Teradata installs [ eweek.com ] , it does n't use SQL .</tokentext>
<sentencetext>WalMart has one of the largest Teradata installs [eweek.com], it doesn't use SQL.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648190</id>
	<title>Other reasons for not using a relational database</title>
	<author>Anonymous</author>
	<datestamp>1269798540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>For me, it's not about scalability at all; I simply don't see a relational database as very good at reflecting the organisation of the data I want to store. For some data sets, it might fit perfectly, but it is usually a far-fetched way to represent the data, in my opinion.</p></htmltext>
<tokenext>For me , it 's not about scalability at all ; I simply do n't see a relational database as very good at reflecting the organisation of the data I want to store .
For some data sets , it might fit perfectly , but it is usually a far-fetched way to represent the data , in my opinion .</tokentext>
<sentencetext>For me, it's not about scalability at all; I simply don't see a relational database as very good at reflecting the organisation of the data I want to store.
For some data sets, it might fit perfectly, but it is usually a far-fetched way to represent the data, in my opinion.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648444</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269800520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways.</p></div><p>And other NoSQL databases solve an entirely unrelated specific problem. Yet people talk about NoSQL as if all were Cassandra. Like your example is certainly a very good reason to use Cassandra, but it is a no reason to use db4o or BerkleyDB or memcached.</p><p>NoSQL databases don't have better write performance than SQL databases. Cassandra has better write performance than strictly consistent databases. There is no reason for NoSQL databases to have eventual consistency. There is no reason for SQL databases to not have eventual consistency. That is whats driving me mad about the NoSQL debate.</p></div>
	</htmltext>
<tokenext>Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways.And other NoSQL databases solve an entirely unrelated specific problem .
Yet people talk about NoSQL as if all were Cassandra .
Like your example is certainly a very good reason to use Cassandra , but it is a no reason to use db4o or BerkleyDB or memcached.NoSQL databases do n't have better write performance than SQL databases .
Cassandra has better write performance than strictly consistent databases .
There is no reason for NoSQL databases to have eventual consistency .
There is no reason for SQL databases to not have eventual consistency .
That is whats driving me mad about the NoSQL debate .</tokentext>
<sentencetext>Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways.And other NoSQL databases solve an entirely unrelated specific problem.
Yet people talk about NoSQL as if all were Cassandra.
Like your example is certainly a very good reason to use Cassandra, but it is a no reason to use db4o or BerkleyDB or memcached.NoSQL databases don't have better write performance than SQL databases.
Cassandra has better write performance than strictly consistent databases.
There is no reason for NoSQL databases to have eventual consistency.
There is no reason for SQL databases to not have eventual consistency.
That is whats driving me mad about the NoSQL debate.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647880</id>
	<title>Someone tell me again...</title>
	<author>Anonymous</author>
	<datestamp>1269796380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext>Why should I give two shits about what database system someone else uses?</htmltext>
<tokenext>Why should I give two shits about what database system someone else uses ?</tokentext>
<sentencetext>Why should I give two shits about what database system someone else uses?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648008</id>
	<title>SQL</title>
	<author>Anonymous</author>
	<datestamp>1269797280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I don't like SQL, but I do like relational databases. If only someone would come up with a relational query language with nice, non-COBOL-esque syntax (maybe lispy...) that just did much the same thing as SQL, and add it to a powerful RDBMS engine like postgresql's or something.  (Yes, I'm aware of the history, and that SQL was added to postgres which followed on from ingres which used a non-sql relational language that was somewhat nicer than SQL... oh, the ironing...)</p></htmltext>
<tokenext>I do n't like SQL , but I do like relational databases .
If only someone would come up with a relational query language with nice , non-COBOL-esque syntax ( maybe lispy... ) that just did much the same thing as SQL , and add it to a powerful RDBMS engine like postgresql 's or something .
( Yes , I 'm aware of the history , and that SQL was added to postgres which followed on from ingres which used a non-sql relational language that was somewhat nicer than SQL... oh , the ironing... )</tokentext>
<sentencetext>I don't like SQL, but I do like relational databases.
If only someone would come up with a relational query language with nice, non-COBOL-esque syntax (maybe lispy...) that just did much the same thing as SQL, and add it to a powerful RDBMS engine like postgresql's or something.
(Yes, I'm aware of the history, and that SQL was added to postgres which followed on from ingres which used a non-sql relational language that was somewhat nicer than SQL... oh, the ironing...)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649966</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269768120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Real business track their data with SQL databases, true. However, real businesses have small numbers of transactions relative to their value. If Walmart had the same revenue but the average sale was a tenth of a cent, their fancy SQL database would be smouldering rubble.</p></div></blockquote><p>This might be true if they sold items for 1/1000th of a cent, but its simply untrue for any sale anywhere.</p><p>Twitters load isn't that impressive, its a poorly written big mess of a service.  Its pretty common knowledge that it could be made far better if they would just use some untrained monkeys.</p><p>Again, facebook<nobr> <wbr></nobr>... bad example.</p><p>You've taken two over night one hit wonders that will be gone in a few years and used them as if they are valid examples of how to do it.  They aren't, they aren't even close.  They are what happens when you grow so fast you don't have a chance in hell of keeping up, so you cobble things together as best you can to survive knowing that its just a matter of time before the fad passes.</p><p>Do I think FB and twitter could survive on MySQL?  Probably not, but on a real DB with real DBAs, more than likely yes.</p></div>
	</htmltext>
<tokenext>Real business track their data with SQL databases , true .
However , real businesses have small numbers of transactions relative to their value .
If Walmart had the same revenue but the average sale was a tenth of a cent , their fancy SQL database would be smouldering rubble.This might be true if they sold items for 1/1000th of a cent , but its simply untrue for any sale anywhere.Twitters load is n't that impressive , its a poorly written big mess of a service .
Its pretty common knowledge that it could be made far better if they would just use some untrained monkeys.Again , facebook ... bad example.You 've taken two over night one hit wonders that will be gone in a few years and used them as if they are valid examples of how to do it .
They are n't , they are n't even close .
They are what happens when you grow so fast you do n't have a chance in hell of keeping up , so you cobble things together as best you can to survive knowing that its just a matter of time before the fad passes.Do I think FB and twitter could survive on MySQL ?
Probably not , but on a real DB with real DBAs , more than likely yes .</tokentext>
<sentencetext>Real business track their data with SQL databases, true.
However, real businesses have small numbers of transactions relative to their value.
If Walmart had the same revenue but the average sale was a tenth of a cent, their fancy SQL database would be smouldering rubble.This might be true if they sold items for 1/1000th of a cent, but its simply untrue for any sale anywhere.Twitters load isn't that impressive, its a poorly written big mess of a service.
Its pretty common knowledge that it could be made far better if they would just use some untrained monkeys.Again, facebook ... bad example.You've taken two over night one hit wonders that will be gone in a few years and used them as if they are valid examples of how to do it.
They aren't, they aren't even close.
They are what happens when you grow so fast you don't have a chance in hell of keeping up, so you cobble things together as best you can to survive knowing that its just a matter of time before the fad passes.Do I think FB and twitter could survive on MySQL?
Probably not, but on a real DB with real DBAs, more than likely yes.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649810</id>
	<title>No, u.</title>
	<author>Anonymous</author>
	<datestamp>1269766920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>After working for two years in Canada doing contract and consultancy for SQL Server (yes I can hear the boos already), it is my educated opinion that most people who design, build and query databases don't have the first clue what they're doing. These people complaining about the performance of a RDBMS is like an "application programmer" who builds a GUI, does no input validation, no error checking or exception handling, and then bitches about the programming language when the app crashes all the time. It's asinine. If you want to develop a database get a database developer, not an application developer.</p><p>Of the approximately 10 companies I worked at while in Canada:</p><p>- 6 had no DRI or other constraints on their databases. At all.<br>- 3 didn't even know what DRI was<br>- One, a company which makes passport and visa software used by governments in multiple companies, and which used nHibernate, refused to understand why (amongst other things) clustering on a GUID key was insane. They fired me after a week of me telling them that their database needed massive redesign.<br>- 3 had nightly database shrinks as part of their maintenance plan.<br>- At not one did the developers writing SQL for GUIs and reports know what a sargeable query was.</p><p>There was also widespread misunderstanding of indexes, no understanding of index internals or fragmentation and no understanding of partitioning at any but one of the companies.</p><p>Guess how many of these companies complained about the performance or consistency of their database on a regular or semi-regular basis?</p></htmltext>
<tokenext>After working for two years in Canada doing contract and consultancy for SQL Server ( yes I can hear the boos already ) , it is my educated opinion that most people who design , build and query databases do n't have the first clue what they 're doing .
These people complaining about the performance of a RDBMS is like an " application programmer " who builds a GUI , does no input validation , no error checking or exception handling , and then bitches about the programming language when the app crashes all the time .
It 's asinine .
If you want to develop a database get a database developer , not an application developer.Of the approximately 10 companies I worked at while in Canada : - 6 had no DRI or other constraints on their databases .
At all.- 3 did n't even know what DRI was- One , a company which makes passport and visa software used by governments in multiple companies , and which used nHibernate , refused to understand why ( amongst other things ) clustering on a GUID key was insane .
They fired me after a week of me telling them that their database needed massive redesign.- 3 had nightly database shrinks as part of their maintenance plan.- At not one did the developers writing SQL for GUIs and reports know what a sargeable query was.There was also widespread misunderstanding of indexes , no understanding of index internals or fragmentation and no understanding of partitioning at any but one of the companies.Guess how many of these companies complained about the performance or consistency of their database on a regular or semi-regular basis ?</tokentext>
<sentencetext>After working for two years in Canada doing contract and consultancy for SQL Server (yes I can hear the boos already), it is my educated opinion that most people who design, build and query databases don't have the first clue what they're doing.
These people complaining about the performance of a RDBMS is like an "application programmer" who builds a GUI, does no input validation, no error checking or exception handling, and then bitches about the programming language when the app crashes all the time.
It's asinine.
If you want to develop a database get a database developer, not an application developer.Of the approximately 10 companies I worked at while in Canada:- 6 had no DRI or other constraints on their databases.
At all.- 3 didn't even know what DRI was- One, a company which makes passport and visa software used by governments in multiple companies, and which used nHibernate, refused to understand why (amongst other things) clustering on a GUID key was insane.
They fired me after a week of me telling them that their database needed massive redesign.- 3 had nightly database shrinks as part of their maintenance plan.- At not one did the developers writing SQL for GUIs and reports know what a sargeable query was.There was also widespread misunderstanding of indexes, no understanding of index internals or fragmentation and no understanding of partitioning at any but one of the companies.Guess how many of these companies complained about the performance or consistency of their database on a regular or semi-regular basis?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648334</id>
	<title>NOSQL Buzz Can Die, I'll use my OODBMS Thanks</title>
	<author>Anonymous</author>
	<datestamp>1269799680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Every damn time an article like this, same bs.</p><p>There are many reasons not to use an RDBMS. It doesn't mean an RDBMS is a failure, but just it might not be the right tool for the job. I don't necessarily see it as a replacement 100\%, but rather a compliment. That said, I'd rather not ever use an RDBMS for various reasons, possibly alluded to here:</p><p>-Lack of desire to deal with Object Relational Mapping. If your application is highly object oriented and a lot goes on at the application layer, an RDBMS is often a bad fit.</p><p>-You need queries that can't easily be done in an RDBMS. Hierarchies (yes, there are clauses in some newer systems, but perform like piss for large datasets) and graph theory (centrality measures, shortest path problems, etc) come to mind.</p><p>-Scaling. Most databases scale only vertically well. You can try replication, but it often is not realistic for some types of applications. Data warehousing, denormalization, read-only dbs, etc are hacks for dealing with this problem.</p><p>-Your domain is objects, why introduce a second domain? Similar to the first, but more of a case where you would definitely use an object db instead.</p><p>-You want object level transactions that do not require additional layers to work at the data level.</p><p>-You judge things based on merit, not marketing, hype, and your own ignorance, hence you've concluded that for your situation, a graph/object database or non-relational store is a better fit.</p><p>There are plenty of other good reasons. I'm tired of hearing arguments both ways that miss the point. Don't use a non-relational database because it is cool or different and you suck at writing SQL. Don't use SQL just because you know it and you're too ignorant to understand the benefits of non-relational stores. As it has been said, use the right tool for the right job.</p><p>I find that is normally not a relational database that I want. When it is, I'll use LISP + Relational DB because they deal with things in a compatible manner. PHP + MySQL on the other hand makes me want to puke. Otherwise, I'm using something like Smalltalk +  or C++ + ObjectDB Vendor. Casandra, NOSQL, and the rest of this stuff is just ignorant crap created by hype machines and I am amazed every time this discussion comes up, the 200 other better technologies out there are ignored. It takes a pretty big asshole to create something new when there's already great solutions out there, not realizing you're going to create the same crap poorly. Of course what can be expected of people like Twitter (Erlang message queues would like a word) and Facebook.</p></htmltext>
<tokenext>Every damn time an article like this , same bs.There are many reasons not to use an RDBMS .
It does n't mean an RDBMS is a failure , but just it might not be the right tool for the job .
I do n't necessarily see it as a replacement 100 \ % , but rather a compliment .
That said , I 'd rather not ever use an RDBMS for various reasons , possibly alluded to here : -Lack of desire to deal with Object Relational Mapping .
If your application is highly object oriented and a lot goes on at the application layer , an RDBMS is often a bad fit.-You need queries that ca n't easily be done in an RDBMS .
Hierarchies ( yes , there are clauses in some newer systems , but perform like piss for large datasets ) and graph theory ( centrality measures , shortest path problems , etc ) come to mind.-Scaling .
Most databases scale only vertically well .
You can try replication , but it often is not realistic for some types of applications .
Data warehousing , denormalization , read-only dbs , etc are hacks for dealing with this problem.-Your domain is objects , why introduce a second domain ?
Similar to the first , but more of a case where you would definitely use an object db instead.-You want object level transactions that do not require additional layers to work at the data level.-You judge things based on merit , not marketing , hype , and your own ignorance , hence you 've concluded that for your situation , a graph/object database or non-relational store is a better fit.There are plenty of other good reasons .
I 'm tired of hearing arguments both ways that miss the point .
Do n't use a non-relational database because it is cool or different and you suck at writing SQL .
Do n't use SQL just because you know it and you 're too ignorant to understand the benefits of non-relational stores .
As it has been said , use the right tool for the right job.I find that is normally not a relational database that I want .
When it is , I 'll use LISP + Relational DB because they deal with things in a compatible manner .
PHP + MySQL on the other hand makes me want to puke .
Otherwise , I 'm using something like Smalltalk + or C + + + ObjectDB Vendor .
Casandra , NOSQL , and the rest of this stuff is just ignorant crap created by hype machines and I am amazed every time this discussion comes up , the 200 other better technologies out there are ignored .
It takes a pretty big asshole to create something new when there 's already great solutions out there , not realizing you 're going to create the same crap poorly .
Of course what can be expected of people like Twitter ( Erlang message queues would like a word ) and Facebook .</tokentext>
<sentencetext>Every damn time an article like this, same bs.There are many reasons not to use an RDBMS.
It doesn't mean an RDBMS is a failure, but just it might not be the right tool for the job.
I don't necessarily see it as a replacement 100\%, but rather a compliment.
That said, I'd rather not ever use an RDBMS for various reasons, possibly alluded to here:-Lack of desire to deal with Object Relational Mapping.
If your application is highly object oriented and a lot goes on at the application layer, an RDBMS is often a bad fit.-You need queries that can't easily be done in an RDBMS.
Hierarchies (yes, there are clauses in some newer systems, but perform like piss for large datasets) and graph theory (centrality measures, shortest path problems, etc) come to mind.-Scaling.
Most databases scale only vertically well.
You can try replication, but it often is not realistic for some types of applications.
Data warehousing, denormalization, read-only dbs, etc are hacks for dealing with this problem.-Your domain is objects, why introduce a second domain?
Similar to the first, but more of a case where you would definitely use an object db instead.-You want object level transactions that do not require additional layers to work at the data level.-You judge things based on merit, not marketing, hype, and your own ignorance, hence you've concluded that for your situation, a graph/object database or non-relational store is a better fit.There are plenty of other good reasons.
I'm tired of hearing arguments both ways that miss the point.
Don't use a non-relational database because it is cool or different and you suck at writing SQL.
Don't use SQL just because you know it and you're too ignorant to understand the benefits of non-relational stores.
As it has been said, use the right tool for the right job.I find that is normally not a relational database that I want.
When it is, I'll use LISP + Relational DB because they deal with things in a compatible manner.
PHP + MySQL on the other hand makes me want to puke.
Otherwise, I'm using something like Smalltalk +  or C++ + ObjectDB Vendor.
Casandra, NOSQL, and the rest of this stuff is just ignorant crap created by hype machines and I am amazed every time this discussion comes up, the 200 other better technologies out there are ignored.
It takes a pretty big asshole to create something new when there's already great solutions out there, not realizing you're going to create the same crap poorly.
Of course what can be expected of people like Twitter (Erlang message queues would like a word) and Facebook.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651574</id>
	<title>Re:More RDBMS dogma</title>
	<author>Joey Vegetables</author>
	<datestamp>1269779760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My roughly 20 years of development experience in litigation, publishing, financial, brokerage, Web, and embedded systems have only very rarely presented me with a data persistence problem for which some type of RDBMS was not an acceptable solution.</p><p>I handle data models similar to those in the medical industry through the <a href="http://en.wikipedia.org/wiki/Entity-attribute-value\_model" title="wikipedia.org">"EAV" (entity/attribute/value) model.</a> [wikipedia.org]  In fact, the linked article discusses clinical findings as a typical example of where EAV might prove useful.   There are tradeoffs for sure, but generally speaking, it works very well when you have a very large number of potential attributes that each entity *might* have, but a much smaller number of attributes that any particular entity *will* have.  For instance there are hundreds of thousands of illnesses or courses of treatment a patient might have, but no one will ever live long enough (or have enough money) to go through all, or more than a tiny fraction, of these.</p><p>What's great about EAV is that you still get most of the benefits of the relational model, as well as most of the benefits of indexing.  The tradeoff is that you do end up having to write more complex code, and sometimes querying can get tricky if your values are of multiple, incompatible types (lots of casting, etc.).  Also, your querying and reporting tools, and your PHBs, all need to be aware that attribute data is being stored as rows rather than columns, and sometimes naive ones aren't.</p></htmltext>
<tokenext>My roughly 20 years of development experience in litigation , publishing , financial , brokerage , Web , and embedded systems have only very rarely presented me with a data persistence problem for which some type of RDBMS was not an acceptable solution.I handle data models similar to those in the medical industry through the " EAV " ( entity/attribute/value ) model .
[ wikipedia.org ] In fact , the linked article discusses clinical findings as a typical example of where EAV might prove useful .
There are tradeoffs for sure , but generally speaking , it works very well when you have a very large number of potential attributes that each entity * might * have , but a much smaller number of attributes that any particular entity * will * have .
For instance there are hundreds of thousands of illnesses or courses of treatment a patient might have , but no one will ever live long enough ( or have enough money ) to go through all , or more than a tiny fraction , of these.What 's great about EAV is that you still get most of the benefits of the relational model , as well as most of the benefits of indexing .
The tradeoff is that you do end up having to write more complex code , and sometimes querying can get tricky if your values are of multiple , incompatible types ( lots of casting , etc. ) .
Also , your querying and reporting tools , and your PHBs , all need to be aware that attribute data is being stored as rows rather than columns , and sometimes naive ones are n't .</tokentext>
<sentencetext>My roughly 20 years of development experience in litigation, publishing, financial, brokerage, Web, and embedded systems have only very rarely presented me with a data persistence problem for which some type of RDBMS was not an acceptable solution.I handle data models similar to those in the medical industry through the "EAV" (entity/attribute/value) model.
[wikipedia.org]  In fact, the linked article discusses clinical findings as a typical example of where EAV might prove useful.
There are tradeoffs for sure, but generally speaking, it works very well when you have a very large number of potential attributes that each entity *might* have, but a much smaller number of attributes that any particular entity *will* have.
For instance there are hundreds of thousands of illnesses or courses of treatment a patient might have, but no one will ever live long enough (or have enough money) to go through all, or more than a tiny fraction, of these.What's great about EAV is that you still get most of the benefits of the relational model, as well as most of the benefits of indexing.
The tradeoff is that you do end up having to write more complex code, and sometimes querying can get tricky if your values are of multiple, incompatible types (lots of casting, etc.).
Also, your querying and reporting tools, and your PHBs, all need to be aware that attribute data is being stored as rows rather than columns, and sometimes naive ones aren't.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648952</id>
	<title>Mainframe-based HVTP Systems Don't use SQL</title>
	<author>emes</author>
	<datestamp>1269803760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For well over 30 years, airline reservation, hotel reservation, and other high volume transaction processing(HVTP) systems that are mainframe-based have not used SQL in the core transaction processing system. They use either the built-in key/value subsystem of TPF/ZTPF, or a slightly more sophisticated subsystem known as TPFDB. Using facilities similar to zOS, failover and recovery happen in record time should it be necessary. This successful real-world system and approach deserves the attention of those who would like to learn how this stuff really works.</p></htmltext>
<tokenext>For well over 30 years , airline reservation , hotel reservation , and other high volume transaction processing ( HVTP ) systems that are mainframe-based have not used SQL in the core transaction processing system .
They use either the built-in key/value subsystem of TPF/ZTPF , or a slightly more sophisticated subsystem known as TPFDB .
Using facilities similar to zOS , failover and recovery happen in record time should it be necessary .
This successful real-world system and approach deserves the attention of those who would like to learn how this stuff really works .</tokentext>
<sentencetext>For well over 30 years, airline reservation, hotel reservation, and other high volume transaction processing(HVTP) systems that are mainframe-based have not used SQL in the core transaction processing system.
They use either the built-in key/value subsystem of TPF/ZTPF, or a slightly more sophisticated subsystem known as TPFDB.
Using facilities similar to zOS, failover and recovery happen in record time should it be necessary.
This successful real-world system and approach deserves the attention of those who would like to learn how this stuff really works.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652740</id>
	<title>Re:SQL performance</title>
	<author>Anonymous</author>
	<datestamp>1269791280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>From my experience, people that complain about SQL performance use "SELECT * FROM table1,table2,table3" and have never here of indices.  I am a SQL noob, and I have seen the magic a guru can perform.  Queries taking 5 seconds to run that took 10 minutes before the guru worked his magic.  The main problem with SQL performance is human-based.</p></htmltext>
<tokenext>From my experience , people that complain about SQL performance use " SELECT * FROM table1,table2,table3 " and have never here of indices .
I am a SQL noob , and I have seen the magic a guru can perform .
Queries taking 5 seconds to run that took 10 minutes before the guru worked his magic .
The main problem with SQL performance is human-based .</tokentext>
<sentencetext>From my experience, people that complain about SQL performance use "SELECT * FROM table1,table2,table3" and have never here of indices.
I am a SQL noob, and I have seen the magic a guru can perform.
Queries taking 5 seconds to run that took 10 minutes before the guru worked his magic.
The main problem with SQL performance is human-based.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648306</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648302</id>
	<title>I'm NOT?</title>
	<author>Anonymous</author>
	<datestamp>1269799500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>From the article:<blockquote><div><p>You Are Not Google</p></div></blockquote><p>
Really?  My paystub says otherwise, you ignorant clod!</p></div>
	</htmltext>
<tokenext>From the article : You Are Not Google Really ?
My paystub says otherwise , you ignorant clod !</tokentext>
<sentencetext>From the article:You Are Not Google
Really?
My paystub says otherwise, you ignorant clod!
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650532</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Zironic</author>
	<datestamp>1269772440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES""</p><p>Hmm, I could actually see that being the case for some applications, probably not one common in the business world but for research it's probably fairly likely you might generate huge datasets where losing individual records wouldn't matter much.</p></htmltext>
<tokenext>" Or is it just that people are throwing consistency out of the window and saying " We can afford to lose a couple of records or have a couple of dangling references here and there , as long as it SCALES " " Hmm , I could actually see that being the case for some applications , probably not one common in the business world but for research it 's probably fairly likely you might generate huge datasets where losing individual records would n't matter much .</tokentext>
<sentencetext>"Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES""Hmm, I could actually see that being the case for some applications, probably not one common in the business world but for research it's probably fairly likely you might generate huge datasets where losing individual records wouldn't matter much.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653312</id>
	<title>function vs form</title>
	<author>Anonymous</author>
	<datestamp>1269797760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I don't know much about the NoSQL movement, but I do know quite a bit about some of the largest SQL databases in the world. Walmart, in particular, runs on a massively parallel SQL database called Teradata. I work for Teradata designing and implementing databases like these for our largest customers. SQL has very little to do with it, in the way English has very little to do with the current economic crisis. Sure, all the subprime mortgages were contracted in the English language, but does anybody think changing languages would have averted the crisis? Relational databases are a means to an end, a way to conduct business in a reliable and efficient manner. As much as I value efficiency, reliability is what drives the purchase decision. Reliability of cash flow. The problems with scalability only matter when cash flow is on the line. Overall, I agree with the thesis, stick with what's reliable at whatever scale you're operating.  A change of database systems when you scale up should be the least of your worries.</p></htmltext>
<tokenext>I do n't know much about the NoSQL movement , but I do know quite a bit about some of the largest SQL databases in the world .
Walmart , in particular , runs on a massively parallel SQL database called Teradata .
I work for Teradata designing and implementing databases like these for our largest customers .
SQL has very little to do with it , in the way English has very little to do with the current economic crisis .
Sure , all the subprime mortgages were contracted in the English language , but does anybody think changing languages would have averted the crisis ?
Relational databases are a means to an end , a way to conduct business in a reliable and efficient manner .
As much as I value efficiency , reliability is what drives the purchase decision .
Reliability of cash flow .
The problems with scalability only matter when cash flow is on the line .
Overall , I agree with the thesis , stick with what 's reliable at whatever scale you 're operating .
A change of database systems when you scale up should be the least of your worries .</tokentext>
<sentencetext>I don't know much about the NoSQL movement, but I do know quite a bit about some of the largest SQL databases in the world.
Walmart, in particular, runs on a massively parallel SQL database called Teradata.
I work for Teradata designing and implementing databases like these for our largest customers.
SQL has very little to do with it, in the way English has very little to do with the current economic crisis.
Sure, all the subprime mortgages were contracted in the English language, but does anybody think changing languages would have averted the crisis?
Relational databases are a means to an end, a way to conduct business in a reliable and efficient manner.
As much as I value efficiency, reliability is what drives the purchase decision.
Reliability of cash flow.
The problems with scalability only matter when cash flow is on the line.
Overall, I agree with the thesis, stick with what's reliable at whatever scale you're operating.
A change of database systems when you scale up should be the least of your worries.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653326</id>
	<title>Re:Some people just want the holy grail</title>
	<author>einhverfr</author>
	<datestamp>1269797880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Anyone that thinks that relational databases are the end-all-be-all of persistent data storage hasn't done enough relational database development to understand some of the limitations.</p></div></blockquote><p>Well, there are some important and underrated strengths of RDBMS's in this area.  No, I don't believe that RDBMS's should replace temp files, and even XML has it's uses.  However, for anything you might possibly need to do complex reporting on at any point in the future, RDBMS's are the way to go.  This is the single biggest reason to use an RDBMS.  Also where you already use an RDBMS, often it can be useful for other bits of info which are outside of the core RDBMS area.</p><p>For example, LedgerSMB uses key/value modelling to store application menus and application settings.  The data model sucks because one is representing freeform data in a tool designed for highly structured data.  However, we put it in the db because it adds less complexity than adding yet another storage media.</p><p>So it's not just the complexity of the data model. And RDBMS's aren't perfect for all things.  However, I would be very surprised of Twitter or Facebook started putting their real business data in NoSQL databases.....</p></div>
	</htmltext>
<tokenext>Anyone that thinks that relational databases are the end-all-be-all of persistent data storage has n't done enough relational database development to understand some of the limitations.Well , there are some important and underrated strengths of RDBMS 's in this area .
No , I do n't believe that RDBMS 's should replace temp files , and even XML has it 's uses .
However , for anything you might possibly need to do complex reporting on at any point in the future , RDBMS 's are the way to go .
This is the single biggest reason to use an RDBMS .
Also where you already use an RDBMS , often it can be useful for other bits of info which are outside of the core RDBMS area.For example , LedgerSMB uses key/value modelling to store application menus and application settings .
The data model sucks because one is representing freeform data in a tool designed for highly structured data .
However , we put it in the db because it adds less complexity than adding yet another storage media.So it 's not just the complexity of the data model .
And RDBMS 's are n't perfect for all things .
However , I would be very surprised of Twitter or Facebook started putting their real business data in NoSQL databases.... .</tokentext>
<sentencetext>Anyone that thinks that relational databases are the end-all-be-all of persistent data storage hasn't done enough relational database development to understand some of the limitations.Well, there are some important and underrated strengths of RDBMS's in this area.
No, I don't believe that RDBMS's should replace temp files, and even XML has it's uses.
However, for anything you might possibly need to do complex reporting on at any point in the future, RDBMS's are the way to go.
This is the single biggest reason to use an RDBMS.
Also where you already use an RDBMS, often it can be useful for other bits of info which are outside of the core RDBMS area.For example, LedgerSMB uses key/value modelling to store application menus and application settings.
The data model sucks because one is representing freeform data in a tool designed for highly structured data.
However, we put it in the db because it adds less complexity than adding yet another storage media.So it's not just the complexity of the data model.
And RDBMS's aren't perfect for all things.
However, I would be very surprised of Twitter or Facebook started putting their real business data in NoSQL databases.....
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649834</id>
	<title>You don't need to be Google to see limits of MySQL</title>
	<author>Anonymous</author>
	<datestamp>1269767100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>If you think that only Google will see the limits of MySQL you need to work in more projects. MySQL is very slow, specially for inserts and updates, and if you have a site with good audience, you will see this limits soon.
<p>
The question is not that is possible to use MySQL, or similar databases, for sites with good audience and a moderate size of data. The question is, how many tricks you will need to keep your site alive!
</p><p>
The other question is that SQL is a good point for hacks (specially SQL injection), and a mess to make maintenance. To avoid hacks you need to filter every variable that enters in your SQL, and to allow maintenance in the future you need to avoid SQL duplications, and have a good control and centralized place to put and manage your SQL strings, or an alter table will means a search over all your code to find what SQL will be playing with some table.
</p><p>
The 3rd point is that modern developers don't want to work with SQL, they want to work with objects and entities. The frameworks for entities that exists today, like JPA, are slow, because there are a lot of layers to make your entities to work with a relational database, and is difficult to use specialized resources that specific databases have to get performance. And of course, relational databases are not created for all of that, but this is what we use today for abstractions like JPA.
</p><p>
We run a site (outside of US) that receives more than 60000 different users per day, with peak of 13000 users at the same time, with average sessions of 1h, and we know that we need a lot of tricks and caches inside of our system to avoid issues with MySQL. And in my opinion, based in real facts and my daily job, MySQL, PHP and Ruby are good only for small projects.
</p><p>
If you will have a project with moderated size, you will need JIT, so your system will run in machine code (not like C, but near) (I recommend Java, specially for back-end), and need to avoid SQL, or at least use some "framework" to manage your SQL in a professional way. I still don't recommend JPA for big projects (maybe version 2.0 is better, but I haven't worked with it yet), but some framework to use entities specialized for your kind of database will be good.
</p><p>
Or if you want, you can do like every one, start with PHP, or Ruby, and MySQL. Than, when performance starts to say hello, you change to Java, or a compiler for PHP (like facebook), and starts the tricks for MySQL. Actually what we want is way to start a projects with a technology that supports the future, but that is also easy and cheap to use just from the beginning.</p></htmltext>
<tokenext>If you think that only Google will see the limits of MySQL you need to work in more projects .
MySQL is very slow , specially for inserts and updates , and if you have a site with good audience , you will see this limits soon .
The question is not that is possible to use MySQL , or similar databases , for sites with good audience and a moderate size of data .
The question is , how many tricks you will need to keep your site alive !
The other question is that SQL is a good point for hacks ( specially SQL injection ) , and a mess to make maintenance .
To avoid hacks you need to filter every variable that enters in your SQL , and to allow maintenance in the future you need to avoid SQL duplications , and have a good control and centralized place to put and manage your SQL strings , or an alter table will means a search over all your code to find what SQL will be playing with some table .
The 3rd point is that modern developers do n't want to work with SQL , they want to work with objects and entities .
The frameworks for entities that exists today , like JPA , are slow , because there are a lot of layers to make your entities to work with a relational database , and is difficult to use specialized resources that specific databases have to get performance .
And of course , relational databases are not created for all of that , but this is what we use today for abstractions like JPA .
We run a site ( outside of US ) that receives more than 60000 different users per day , with peak of 13000 users at the same time , with average sessions of 1h , and we know that we need a lot of tricks and caches inside of our system to avoid issues with MySQL .
And in my opinion , based in real facts and my daily job , MySQL , PHP and Ruby are good only for small projects .
If you will have a project with moderated size , you will need JIT , so your system will run in machine code ( not like C , but near ) ( I recommend Java , specially for back-end ) , and need to avoid SQL , or at least use some " framework " to manage your SQL in a professional way .
I still do n't recommend JPA for big projects ( maybe version 2.0 is better , but I have n't worked with it yet ) , but some framework to use entities specialized for your kind of database will be good .
Or if you want , you can do like every one , start with PHP , or Ruby , and MySQL .
Than , when performance starts to say hello , you change to Java , or a compiler for PHP ( like facebook ) , and starts the tricks for MySQL .
Actually what we want is way to start a projects with a technology that supports the future , but that is also easy and cheap to use just from the beginning .</tokentext>
<sentencetext>If you think that only Google will see the limits of MySQL you need to work in more projects.
MySQL is very slow, specially for inserts and updates, and if you have a site with good audience, you will see this limits soon.
The question is not that is possible to use MySQL, or similar databases, for sites with good audience and a moderate size of data.
The question is, how many tricks you will need to keep your site alive!
The other question is that SQL is a good point for hacks (specially SQL injection), and a mess to make maintenance.
To avoid hacks you need to filter every variable that enters in your SQL, and to allow maintenance in the future you need to avoid SQL duplications, and have a good control and centralized place to put and manage your SQL strings, or an alter table will means a search over all your code to find what SQL will be playing with some table.
The 3rd point is that modern developers don't want to work with SQL, they want to work with objects and entities.
The frameworks for entities that exists today, like JPA, are slow, because there are a lot of layers to make your entities to work with a relational database, and is difficult to use specialized resources that specific databases have to get performance.
And of course, relational databases are not created for all of that, but this is what we use today for abstractions like JPA.
We run a site (outside of US) that receives more than 60000 different users per day, with peak of 13000 users at the same time, with average sessions of 1h, and we know that we need a lot of tricks and caches inside of our system to avoid issues with MySQL.
And in my opinion, based in real facts and my daily job, MySQL, PHP and Ruby are good only for small projects.
If you will have a project with moderated size, you will need JIT, so your system will run in machine code (not like C, but near) (I recommend Java, specially for back-end), and need to avoid SQL, or at least use some "framework" to manage your SQL in a professional way.
I still don't recommend JPA for big projects (maybe version 2.0 is better, but I haven't worked with it yet), but some framework to use entities specialized for your kind of database will be good.
Or if you want, you can do like every one, start with PHP, or Ruby, and MySQL.
Than, when performance starts to say hello, you change to Java, or a compiler for PHP (like facebook), and starts the tricks for MySQL.
Actually what we want is way to start a projects with a technology that supports the future, but that is also easy and cheap to use just from the beginning.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649640</id>
	<title>Easy.</title>
	<author>Estanislao Martínez</author>
	<datestamp>1269808920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>Why should I give two shits about what database system someone else uses?</p></div></blockquote><p>Because they're gonna tell your non-technical boss to make you use it, and he's gonna listen when they start telling him that Google, Twitter and Facebook do.</p></div>
	</htmltext>
<tokenext>Why should I give two shits about what database system someone else uses ? Because they 're gon na tell your non-technical boss to make you use it , and he 's gon na listen when they start telling him that Google , Twitter and Facebook do .</tokentext>
<sentencetext>Why should I give two shits about what database system someone else uses?Because they're gonna tell your non-technical boss to make you use it, and he's gonna listen when they start telling him that Google, Twitter and Facebook do.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31655826</id>
	<title>Reply from Cassandra's Eric Evans</title>
	<author>beemishboy</author>
	<datestamp>1269871320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Eric Evans, who coined the term NoSQL and is a committer on the Cassandra project, responded in a blog post:<br>
<br>
<a href="http://blog.sym-link.com/2010/03/28/haters\_gonna\_hate.html" title="sym-link.com" rel="nofollow">http://blog.sym-link.com/2010/03/28/haters\_gonna\_hate.html</a> [sym-link.com]</htmltext>
<tokenext>Eric Evans , who coined the term NoSQL and is a committer on the Cassandra project , responded in a blog post : http : //blog.sym-link.com/2010/03/28/haters \ _gonna \ _hate.html [ sym-link.com ]</tokentext>
<sentencetext>Eric Evans, who coined the term NoSQL and is a committer on the Cassandra project, responded in a blog post:

http://blog.sym-link.com/2010/03/28/haters\_gonna\_hate.html [sym-link.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650388</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Anonymous</author>
	<datestamp>1269771420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You can reuse functions but you can't extend them and that's where OOs reuse shines.</p></div><p>Have you ever programmed in anything other than OO? I was reusing and extending functions in several different languages long before OO became fashionable.</p><p><div class="quote"><p>It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.</p></div><p>Yeah, until the customer asks for audit logging on everything that saves data and for a dozen distant nodes to start talking to each other. Then you have to redesign the tree from near enough the ground up. Which has happened on pretty much every OO enterprise application project I've ever seen.</p><p>Face it, for almost anything except games and GUIs, OO bites. </p></div>
	</htmltext>
<tokenext>You can reuse functions but you ca n't extend them and that 's where OOs reuse shines.Have you ever programmed in anything other than OO ?
I was reusing and extending functions in several different languages long before OO became fashionable.It 's very powerful to be able to lay out your code as a tree and control the reuse 'flow ' at the nodes.Yeah , until the customer asks for audit logging on everything that saves data and for a dozen distant nodes to start talking to each other .
Then you have to redesign the tree from near enough the ground up .
Which has happened on pretty much every OO enterprise application project I 've ever seen.Face it , for almost anything except games and GUIs , OO bites .</tokentext>
<sentencetext>You can reuse functions but you can't extend them and that's where OOs reuse shines.Have you ever programmed in anything other than OO?
I was reusing and extending functions in several different languages long before OO became fashionable.It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.Yeah, until the customer asks for audit logging on everything that saves data and for a dozen distant nodes to start talking to each other.
Then you have to redesign the tree from near enough the ground up.
Which has happened on pretty much every OO enterprise application project I've ever seen.Face it, for almost anything except games and GUIs, OO bites. 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31661050</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Anonymous</author>
	<datestamp>1269894420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ah, but OO DOES make code re-use easier.  A whole LOT easier.  Objects are really, really easy to repurpose.  It's a beautiful thing.</p><p>I don't think that's the best thing about OO, but you have to admit it's up there in the top ten.</p><p>Personally, my favorite thing about OO is that if you do it right, it's almost completely self documenting. You can organize your objects in such a way that people can intuitively guess what they do and what they're for. Maintenance becomes a hell of a lot easier for everyone as a result.</p><p>Another lovely thing is polymorphism.  This one feature alone makes OO full of win.  All the common code goes in the abstract base class, and all child classes implement the same abstract methods from the base class -- so each thing that you do exists in one and only one place in your software, and you can add new sub-types anytime you want.</p><p>OO is like magic.</p><p>I think maybe you're a little crusty.</p></htmltext>
<tokenext>Ah , but OO DOES make code re-use easier .
A whole LOT easier .
Objects are really , really easy to repurpose .
It 's a beautiful thing.I do n't think that 's the best thing about OO , but you have to admit it 's up there in the top ten.Personally , my favorite thing about OO is that if you do it right , it 's almost completely self documenting .
You can organize your objects in such a way that people can intuitively guess what they do and what they 're for .
Maintenance becomes a hell of a lot easier for everyone as a result.Another lovely thing is polymorphism .
This one feature alone makes OO full of win .
All the common code goes in the abstract base class , and all child classes implement the same abstract methods from the base class -- so each thing that you do exists in one and only one place in your software , and you can add new sub-types anytime you want.OO is like magic.I think maybe you 're a little crusty .</tokentext>
<sentencetext>Ah, but OO DOES make code re-use easier.
A whole LOT easier.
Objects are really, really easy to repurpose.
It's a beautiful thing.I don't think that's the best thing about OO, but you have to admit it's up there in the top ten.Personally, my favorite thing about OO is that if you do it right, it's almost completely self documenting.
You can organize your objects in such a way that people can intuitively guess what they do and what they're for.
Maintenance becomes a hell of a lot easier for everyone as a result.Another lovely thing is polymorphism.
This one feature alone makes OO full of win.
All the common code goes in the abstract base class, and all child classes implement the same abstract methods from the base class -- so each thing that you do exists in one and only one place in your software, and you can add new sub-types anytime you want.OO is like magic.I think maybe you're a little crusty.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653236</id>
	<title>Re:Walmart's primary business isn't online</title>
	<author>einhverfr</author>
	<datestamp>1269796560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You are right.  There is no comparison.  Having worked with POS frameworks and the like I can tell you performance is a MUCH bigger issue there.</p><p>Interestingly the two largest databases I help with regarding LedgerSMB are a financial services business with over a hundred employees and the other is a convenience store with two tills.  And with the POS environment, you have to have top performance.  A 10 second delay is something that needs to be fixed quickly and a 30 second delay is almost unworkable.  So yes, no comparison.  Performance is MUCH more important on the brick and mortar retail end.....</p></htmltext>
<tokenext>You are right .
There is no comparison .
Having worked with POS frameworks and the like I can tell you performance is a MUCH bigger issue there.Interestingly the two largest databases I help with regarding LedgerSMB are a financial services business with over a hundred employees and the other is a convenience store with two tills .
And with the POS environment , you have to have top performance .
A 10 second delay is something that needs to be fixed quickly and a 30 second delay is almost unworkable .
So yes , no comparison .
Performance is MUCH more important on the brick and mortar retail end.... .</tokentext>
<sentencetext>You are right.
There is no comparison.
Having worked with POS frameworks and the like I can tell you performance is a MUCH bigger issue there.Interestingly the two largest databases I help with regarding LedgerSMB are a financial services business with over a hundred employees and the other is a convenience store with two tills.
And with the POS environment, you have to have top performance.
A 10 second delay is something that needs to be fixed quickly and a 30 second delay is almost unworkable.
So yes, no comparison.
Performance is MUCH more important on the brick and mortar retail end.....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647896</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652042</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>mukund</author>
	<datestamp>1269784260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>One thing that many people don't seem to get right: Using these "NoSQL" databases doesn't mean that you don't get ACID. Many key-value databases support ACID just fine:</p><ul>
<li> <a href="http://www.oracle.com/technology/documentation/berkeley-db/db/gsg\_txn/C/index.html" title="oracle.com">Berkeley DB transaction support</a> [oracle.com]; Berkeley DB used to even include XA support for a distributed transaction manager.. but <a href="http://www.oracle.com/technology/documentation/berkeley-db/db/programmer\_reference/changelog\_4\_8.html#id1655895" title="oracle.com">that seems to have been removed</a> [oracle.com].</li><li> <a href="http://1978th.net/tokyocabinet/spex-en.html#features" title="1978th.net">Tokyo Cabinet transaction features</a> [1978th.net] </li></ul><p>You've got to remember that (simplifying drastically,) SQL is a query language layered on top of a "NoSQL" style database (whether built into the SQL DBMS implementation, or a 3rd party one). Such "NoSQL" databases have to be ACID capable in their native API and implementation first.</p></htmltext>
<tokenext>One thing that many people do n't seem to get right : Using these " NoSQL " databases does n't mean that you do n't get ACID .
Many key-value databases support ACID just fine : Berkeley DB transaction support [ oracle.com ] ; Berkeley DB used to even include XA support for a distributed transaction manager.. but that seems to have been removed [ oracle.com ] .
Tokyo Cabinet transaction features [ 1978th.net ] You 've got to remember that ( simplifying drastically , ) SQL is a query language layered on top of a " NoSQL " style database ( whether built into the SQL DBMS implementation , or a 3rd party one ) .
Such " NoSQL " databases have to be ACID capable in their native API and implementation first .</tokentext>
<sentencetext>One thing that many people don't seem to get right: Using these "NoSQL" databases doesn't mean that you don't get ACID.
Many key-value databases support ACID just fine:
 Berkeley DB transaction support [oracle.com]; Berkeley DB used to even include XA support for a distributed transaction manager.. but that seems to have been removed [oracle.com].
Tokyo Cabinet transaction features [1978th.net] You've got to remember that (simplifying drastically,) SQL is a query language layered on top of a "NoSQL" style database (whether built into the SQL DBMS implementation, or a 3rd party one).
Such "NoSQL" databases have to be ACID capable in their native API and implementation first.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651804</id>
	<title>Object databases</title>
	<author>countach</author>
	<datestamp>1269781980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>All our languages are now object, but we're still using non-object databases and mapping between rows and columns and objects. WHY?? Yes, tools can  help you map, but its a bandaid, it screws up performance on all but simple cases. And it means you can't do queries using the same model as your language.</p><p>Yes, relational algebra is a useful query tool, but there is no need to be beholden to relational table structures to get relational algebra. Neither is the so-called object-relational features of postgresql going to cut it. You can't even do a query and get back a list of objects of different types for goodness sake.</p></htmltext>
<tokenext>All our languages are now object , but we 're still using non-object databases and mapping between rows and columns and objects .
WHY ? ? Yes , tools can help you map , but its a bandaid , it screws up performance on all but simple cases .
And it means you ca n't do queries using the same model as your language.Yes , relational algebra is a useful query tool , but there is no need to be beholden to relational table structures to get relational algebra .
Neither is the so-called object-relational features of postgresql going to cut it .
You ca n't even do a query and get back a list of objects of different types for goodness sake .</tokentext>
<sentencetext>All our languages are now object, but we're still using non-object databases and mapping between rows and columns and objects.
WHY?? Yes, tools can  help you map, but its a bandaid, it screws up performance on all but simple cases.
And it means you can't do queries using the same model as your language.Yes, relational algebra is a useful query tool, but there is no need to be beholden to relational table structures to get relational algebra.
Neither is the so-called object-relational features of postgresql going to cut it.
You can't even do a query and get back a list of objects of different types for goodness sake.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31729282</id>
	<title>Re:XML (of databases)?</title>
	<author>ckaminski</author>
	<datestamp>1270394340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Check out Berkeley DB XML<br><br>http://www.oracle.com/database/berkeley-db/xml/index.html</htmltext>
<tokenext>Check out Berkeley DB XMLhttp : //www.oracle.com/database/berkeley-db/xml/index.html</tokentext>
<sentencetext>Check out Berkeley DB XMLhttp://www.oracle.com/database/berkeley-db/xml/index.html</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648332</id>
	<title>NoSQL isn't just for large-scale apps</title>
	<author>tomhudson</author>
	<datestamp>1269799680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's quite possible to use the same design concepts to develop smaller apps that don't need the overhead of an sql database. Don't forget that before RDBMS came out, hierarchical file systems were used as data stores.
<p>
In Soviet Russia, NoSQL kills off Devs!</p></htmltext>
<tokenext>It 's quite possible to use the same design concepts to develop smaller apps that do n't need the overhead of an sql database .
Do n't forget that before RDBMS came out , hierarchical file systems were used as data stores .
In Soviet Russia , NoSQL kills off Devs !</tokentext>
<sentencetext>It's quite possible to use the same design concepts to develop smaller apps that don't need the overhead of an sql database.
Don't forget that before RDBMS came out, hierarchical file systems were used as data stores.
In Soviet Russia, NoSQL kills off Devs!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653484</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>grepya</author>
	<datestamp>1269799680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES". Because I can build something that scales if it doesn't have to maintain ACID, too. The difficulty is in having \_both\_ ACID and scalability.</p></div><p> That's exactly right. To any experienced server engineer/architect, it's obvious that  much greater scaling --  both horizontal (automatic sharding of data across nodes) and vertical (more writes/second/node -- can be achieved if you give up the absolute guarantee of zero data loss (...while still usually keeping data *consistency* in the non-lost portion of the data). Many of the social networking type applications... twitter, facebook and the likes, can probably afford that risk. Given that... you can do many many more txns/s with  key-value type database instead of the transactionally oriented OLTP type databases.  Now, for a smaller organization (shoe-string startups and such), the RDBMS model still has many benefits that can't be ignored --- vast "googleable" knowledge base behind the traditional software products, larger  candidate pool with expertise in said systems etc.   Unfortunately there really is no standard answer here other than evaluate your own situation carefully and make up your mind based on all data (most of which is  available only to you).</p></div>
	</htmltext>
<tokenext>Or is it just that people are throwing consistency out of the window and saying " We can afford to lose a couple of records or have a couple of dangling references here and there , as long as it SCALES " .
Because I can build something that scales if it does n't have to maintain ACID , too .
The difficulty is in having \ _both \ _ ACID and scalability .
That 's exactly right .
To any experienced server engineer/architect , it 's obvious that much greater scaling -- both horizontal ( automatic sharding of data across nodes ) and vertical ( more writes/second/node -- can be achieved if you give up the absolute guarantee of zero data loss ( ...while still usually keeping data * consistency * in the non-lost portion of the data ) .
Many of the social networking type applications... twitter , facebook and the likes , can probably afford that risk .
Given that... you can do many many more txns/s with key-value type database instead of the transactionally oriented OLTP type databases .
Now , for a smaller organization ( shoe-string startups and such ) , the RDBMS model still has many benefits that ca n't be ignored --- vast " googleable " knowledge base behind the traditional software products , larger candidate pool with expertise in said systems etc .
Unfortunately there really is no standard answer here other than evaluate your own situation carefully and make up your mind based on all data ( most of which is available only to you ) .</tokentext>
<sentencetext>Or is it just that people are throwing consistency out of the window and saying "We can afford to lose a couple of records or have a couple of dangling references here and there, as long as it SCALES".
Because I can build something that scales if it doesn't have to maintain ACID, too.
The difficulty is in having \_both\_ ACID and scalability.
That's exactly right.
To any experienced server engineer/architect, it's obvious that  much greater scaling --  both horizontal (automatic sharding of data across nodes) and vertical (more writes/second/node -- can be achieved if you give up the absolute guarantee of zero data loss (...while still usually keeping data *consistency* in the non-lost portion of the data).
Many of the social networking type applications... twitter, facebook and the likes, can probably afford that risk.
Given that... you can do many many more txns/s with  key-value type database instead of the transactionally oriented OLTP type databases.
Now, for a smaller organization (shoe-string startups and such), the RDBMS model still has many benefits that can't be ignored --- vast "googleable" knowledge base behind the traditional software products, larger  candidate pool with expertise in said systems etc.
Unfortunately there really is no standard answer here other than evaluate your own situation carefully and make up your mind based on all data (most of which is  available only to you).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648248</id>
	<title>Re:XML (of databases)?</title>
	<author>kuhneng</author>
	<datestamp>1269799080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Oracle and DB2 both support the SQL/XML standard and provide quite a bit of functionality for native handling of XML.  Both can store structured / compressed representations in a native XML type (with or without a predefined schema) and use XPath-based indexes for efficient query execution.</p><p>Wonderful stuff, and one of the few features I really miss back in the PostgreSQL world.</p></htmltext>
<tokenext>Oracle and DB2 both support the SQL/XML standard and provide quite a bit of functionality for native handling of XML .
Both can store structured / compressed representations in a native XML type ( with or without a predefined schema ) and use XPath-based indexes for efficient query execution.Wonderful stuff , and one of the few features I really miss back in the PostgreSQL world .</tokentext>
<sentencetext>Oracle and DB2 both support the SQL/XML standard and provide quite a bit of functionality for native handling of XML.
Both can store structured / compressed representations in a native XML type (with or without a predefined schema) and use XPath-based indexes for efficient query execution.Wonderful stuff, and one of the few features I really miss back in the PostgreSQL world.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649260</id>
	<title>if you think devs are stupid...</title>
	<author>ruurd</author>
	<datestamp>1269805980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Oh shoei. Must have been a slow day. Yes everybody that uses an SQL database for no good reason is insane. Yes everybody that uses a NoSQL database because it is the latest-and-greatest has the same affliction. Use what fits your purpose. SQL or NoSQL? Does not matter.</htmltext>
<tokenext>Oh shoei .
Must have been a slow day .
Yes everybody that uses an SQL database for no good reason is insane .
Yes everybody that uses a NoSQL database because it is the latest-and-greatest has the same affliction .
Use what fits your purpose .
SQL or NoSQL ?
Does not matter .</tokentext>
<sentencetext>Oh shoei.
Must have been a slow day.
Yes everybody that uses an SQL database for no good reason is insane.
Yes everybody that uses a NoSQL database because it is the latest-and-greatest has the same affliction.
Use what fits your purpose.
SQL or NoSQL?
Does not matter.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048</id>
	<title>More RDBMS dogma</title>
	<author>Angst Badger</author>
	<datestamp>1269797520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Use the right tool for the job, except databases, eh?</p><p>The simple fact of the matter is that not every app is aiming for Google's scale. (Not every app is web-based or even going to be web-based, though people seem to forget that.) And even some large-scale apps don't fit the relational model very well, medical records being one of the more outstanding examples.</p><p>And yes, I <i>have</i> read Codd and Date and understand the relational model and its benefits very well, and it annoys me to no end when people break the relational model without realizing or understanding what it costs them. That said, sometimes those costs are acceptable, and sometimes an application requires features that the relational model does not (and in fact cannot) bring to the table.</p><p>It may be, as with every other silver bullet fad, that what's at work here is the basic human tendency to become familiar with something, begin to see everything in terms of it, and then try to persuade anyone who'll listen that they are in possession of the all-singing, all-dancing solution to all problems. Today, it's Ruby, multi-touch interfaces, and functional programming. But not very long ago it was COBOL and CICS. And while one must acknowledge that progress has been made, it is equally obvious that progress will continue to be made and that "one size fits all" is always BS, even in clothing.</p></htmltext>
<tokenext>Use the right tool for the job , except databases , eh ? The simple fact of the matter is that not every app is aiming for Google 's scale .
( Not every app is web-based or even going to be web-based , though people seem to forget that .
) And even some large-scale apps do n't fit the relational model very well , medical records being one of the more outstanding examples.And yes , I have read Codd and Date and understand the relational model and its benefits very well , and it annoys me to no end when people break the relational model without realizing or understanding what it costs them .
That said , sometimes those costs are acceptable , and sometimes an application requires features that the relational model does not ( and in fact can not ) bring to the table.It may be , as with every other silver bullet fad , that what 's at work here is the basic human tendency to become familiar with something , begin to see everything in terms of it , and then try to persuade anyone who 'll listen that they are in possession of the all-singing , all-dancing solution to all problems .
Today , it 's Ruby , multi-touch interfaces , and functional programming .
But not very long ago it was COBOL and CICS .
And while one must acknowledge that progress has been made , it is equally obvious that progress will continue to be made and that " one size fits all " is always BS , even in clothing .</tokentext>
<sentencetext>Use the right tool for the job, except databases, eh?The simple fact of the matter is that not every app is aiming for Google's scale.
(Not every app is web-based or even going to be web-based, though people seem to forget that.
) And even some large-scale apps don't fit the relational model very well, medical records being one of the more outstanding examples.And yes, I have read Codd and Date and understand the relational model and its benefits very well, and it annoys me to no end when people break the relational model without realizing or understanding what it costs them.
That said, sometimes those costs are acceptable, and sometimes an application requires features that the relational model does not (and in fact cannot) bring to the table.It may be, as with every other silver bullet fad, that what's at work here is the basic human tendency to become familiar with something, begin to see everything in terms of it, and then try to persuade anyone who'll listen that they are in possession of the all-singing, all-dancing solution to all problems.
Today, it's Ruby, multi-touch interfaces, and functional programming.
But not very long ago it was COBOL and CICS.
And while one must acknowledge that progress has been made, it is equally obvious that progress will continue to be made and that "one size fits all" is always BS, even in clothing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649906</id>
	<title>PhDs at Google at totally idiots then...</title>
	<author>Liquid-Gecka</author>
	<datestamp>1269767640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Joe Stump wrote a post that is a perfect response to this insanity.</p><p>

<a href="http://stu.mp/category/nosql" title="stu.mp">http://stu.mp/category/nosql</a> [stu.mp]

</p><p>Why is it that all the people working at scale seems to be going with NoSQL solutions? Are all the devs at Google, Facebook, Twitter, Digg, Redit, etc total idiots or in fact is there a problem that they face that is actually real?</p><p>Anybody that sites Amazon, Walmart or any large retailer as an example of why SQL scales is missing the point. Retails have very few write operations compared to the read load. The vast majority of the load hits databases that serve reads and have a high tolerance for write latency. This is a field SQL is good at solving.</p><p>On the other hand, social sites that have massive cross user data ties and constant write updates where latency is very important don't fit this model that well. Sure, you can remove SQL replication from the mix, use independent instances of MySQL serving fractions of the overall site, with redundancy between them but if you do that you have functionally built a NoSQL data store. The concept isn't to get right of SQL, its to get rid of the relational aspect of data storage. You can no longer rely on all your data being available to a single SQL statement. </p><p>Being an operations guy though I should point out the number one failing of SQL in my world. If you assume that, on average, a machine will either crash or have some sort of hardware failure once a year and you consider a site with 1,000 machines then you see that nearly 3 machines will die every day. Even if you count on 2 years of continuous uptime that is over 1 a day. with 10,000 machines your failure rate is 27 per day, 100,000 machines is 273. This means that any database layer that requires a large number of machines has to build in a recovery layer. Clients need to know that a node is down, when it comes back it needs to have data uploaded to it.. etc. The NoSQL solutions like Cassandra manage this automatically. Trying to do this with MySQL becomes really complicated and you end up implementing all the same logic and constraints in NoSQL solutions anyways. I have seen this happen twice now.</p></htmltext>
<tokenext>Joe Stump wrote a post that is a perfect response to this insanity .
http : //stu.mp/category/nosql [ stu.mp ] Why is it that all the people working at scale seems to be going with NoSQL solutions ?
Are all the devs at Google , Facebook , Twitter , Digg , Redit , etc total idiots or in fact is there a problem that they face that is actually real ? Anybody that sites Amazon , Walmart or any large retailer as an example of why SQL scales is missing the point .
Retails have very few write operations compared to the read load .
The vast majority of the load hits databases that serve reads and have a high tolerance for write latency .
This is a field SQL is good at solving.On the other hand , social sites that have massive cross user data ties and constant write updates where latency is very important do n't fit this model that well .
Sure , you can remove SQL replication from the mix , use independent instances of MySQL serving fractions of the overall site , with redundancy between them but if you do that you have functionally built a NoSQL data store .
The concept is n't to get right of SQL , its to get rid of the relational aspect of data storage .
You can no longer rely on all your data being available to a single SQL statement .
Being an operations guy though I should point out the number one failing of SQL in my world .
If you assume that , on average , a machine will either crash or have some sort of hardware failure once a year and you consider a site with 1,000 machines then you see that nearly 3 machines will die every day .
Even if you count on 2 years of continuous uptime that is over 1 a day .
with 10,000 machines your failure rate is 27 per day , 100,000 machines is 273 .
This means that any database layer that requires a large number of machines has to build in a recovery layer .
Clients need to know that a node is down , when it comes back it needs to have data uploaded to it.. etc. The NoSQL solutions like Cassandra manage this automatically .
Trying to do this with MySQL becomes really complicated and you end up implementing all the same logic and constraints in NoSQL solutions anyways .
I have seen this happen twice now .</tokentext>
<sentencetext>Joe Stump wrote a post that is a perfect response to this insanity.
http://stu.mp/category/nosql [stu.mp]

Why is it that all the people working at scale seems to be going with NoSQL solutions?
Are all the devs at Google, Facebook, Twitter, Digg, Redit, etc total idiots or in fact is there a problem that they face that is actually real?Anybody that sites Amazon, Walmart or any large retailer as an example of why SQL scales is missing the point.
Retails have very few write operations compared to the read load.
The vast majority of the load hits databases that serve reads and have a high tolerance for write latency.
This is a field SQL is good at solving.On the other hand, social sites that have massive cross user data ties and constant write updates where latency is very important don't fit this model that well.
Sure, you can remove SQL replication from the mix, use independent instances of MySQL serving fractions of the overall site, with redundancy between them but if you do that you have functionally built a NoSQL data store.
The concept isn't to get right of SQL, its to get rid of the relational aspect of data storage.
You can no longer rely on all your data being available to a single SQL statement.
Being an operations guy though I should point out the number one failing of SQL in my world.
If you assume that, on average, a machine will either crash or have some sort of hardware failure once a year and you consider a site with 1,000 machines then you see that nearly 3 machines will die every day.
Even if you count on 2 years of continuous uptime that is over 1 a day.
with 10,000 machines your failure rate is 27 per day, 100,000 machines is 273.
This means that any database layer that requires a large number of machines has to build in a recovery layer.
Clients need to know that a node is down, when it comes back it needs to have data uploaded to it.. etc. The NoSQL solutions like Cassandra manage this automatically.
Trying to do this with MySQL becomes really complicated and you end up implementing all the same logic and constraints in NoSQL solutions anyways.
I have seen this happen twice now.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648126</id>
	<title>Re:Some people just want the holy grail</title>
	<author>Anonymous</author>
	<datestamp>1269798120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>And yes, OO and such also belong to this. Not the concept themselves, but the way most people talk about. OO means code re-use right?</p><p>If you said yes, then you are a manager, go put on your tie, you will never be any good at coding.</p></div></blockquote><p>Don't get so high and mighty.  The answer to "OO means code re-use right?" is "Yes."  This answer in no way implies that it's the only means of code re-use; you probably meant your sarcastic hypothetical to mean "Re-use means OO, right?"</p></div>
	</htmltext>
<tokenext>And yes , OO and such also belong to this .
Not the concept themselves , but the way most people talk about .
OO means code re-use right ? If you said yes , then you are a manager , go put on your tie , you will never be any good at coding.Do n't get so high and mighty .
The answer to " OO means code re-use right ?
" is " Yes .
" This answer in no way implies that it 's the only means of code re-use ; you probably meant your sarcastic hypothetical to mean " Re-use means OO , right ?
"</tokentext>
<sentencetext>And yes, OO and such also belong to this.
Not the concept themselves, but the way most people talk about.
OO means code re-use right?If you said yes, then you are a manager, go put on your tie, you will never be any good at coding.Don't get so high and mighty.
The answer to "OO means code re-use right?
" is "Yes.
"  This answer in no way implies that it's the only means of code re-use; you probably meant your sarcastic hypothetical to mean "Re-use means OO, right?
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070</id>
	<title>Re:Some people just want the holy grail</title>
	<author>tukang</author>
	<datestamp>1269797820000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p> <i>OO does make code re-use a bit easier BUT that is NOT the claim that people often make. Trust me, I ask this in interviews and it is always the same answer. Apparently you can't re-use functions. No way, no how. NEXT! </i> </p><p>You can reuse functions but you can't extend them and that's where OOs reuse shines. It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.</p></htmltext>
<tokenext>OO does make code re-use a bit easier BUT that is NOT the claim that people often make .
Trust me , I ask this in interviews and it is always the same answer .
Apparently you ca n't re-use functions .
No way , no how .
NEXT ! You can reuse functions but you ca n't extend them and that 's where OOs reuse shines .
It 's very powerful to be able to lay out your code as a tree and control the reuse 'flow ' at the nodes .</tokentext>
<sentencetext> OO does make code re-use a bit easier BUT that is NOT the claim that people often make.
Trust me, I ask this in interviews and it is always the same answer.
Apparently you can't re-use functions.
No way, no how.
NEXT!  You can reuse functions but you can't extend them and that's where OOs reuse shines.
It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650618</id>
	<title>Why I am considering NoSQL</title>
	<author>Apoptosis66</author>
	<datestamp>1269772980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>My team is currently considering a "NoSQL" solution moving away from PostgreSQL, and the reason is:  We desperately need Multimaster over the WAN that handles split brain situations gracefully.  Its a tough problem and frankly no RDBMS handles it well.  I suspect any group who has had to support multiple disperse locations has the same thought.</htmltext>
<tokenext>My team is currently considering a " NoSQL " solution moving away from PostgreSQL , and the reason is : We desperately need Multimaster over the WAN that handles split brain situations gracefully .
Its a tough problem and frankly no RDBMS handles it well .
I suspect any group who has had to support multiple disperse locations has the same thought .</tokentext>
<sentencetext>My team is currently considering a "NoSQL" solution moving away from PostgreSQL, and the reason is:  We desperately need Multimaster over the WAN that handles split brain situations gracefully.
Its a tough problem and frankly no RDBMS handles it well.
I suspect any group who has had to support multiple disperse locations has the same thought.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652936</id>
	<title>Replication</title>
	<author>Anonymous</author>
	<datestamp>1269794100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Replication, Replication, Replication....

Here's the deal. Our software runs just fine on PostgreSQL, however if our datacenter goes down or a disaster hits, I need to have that data in multiple places at once. I can't be running queries through a Master node across a continent and then replicate to slaves.

This is the big problem with RDBMS. How to replicate efficiently and quickly without sacrificing performance. Cassandra seems to be a solution that works and works well. I probably will never be a Facebook fielding 100,000 queries per second to a 500TB database,but I do need to replicate efficiently. Any Key/Value store allows this.

I'm interested to see how other replicate their databases. I however don't want to hear, "Just do a nightly dump and then you have backup" or anything like that.

I want to hear a valid, good solution to replication. If there is a database that uses SQL for it's query language that as microsecond query times in a huge database that replicates pretty much "real-time" meaning within seconds/minutes let me know. Because PGPOOL-II just isn't cutting it.</htmltext>
<tokenext>Replication , Replication , Replication... . Here 's the deal .
Our software runs just fine on PostgreSQL , however if our datacenter goes down or a disaster hits , I need to have that data in multiple places at once .
I ca n't be running queries through a Master node across a continent and then replicate to slaves .
This is the big problem with RDBMS .
How to replicate efficiently and quickly without sacrificing performance .
Cassandra seems to be a solution that works and works well .
I probably will never be a Facebook fielding 100,000 queries per second to a 500TB database,but I do need to replicate efficiently .
Any Key/Value store allows this .
I 'm interested to see how other replicate their databases .
I however do n't want to hear , " Just do a nightly dump and then you have backup " or anything like that .
I want to hear a valid , good solution to replication .
If there is a database that uses SQL for it 's query language that as microsecond query times in a huge database that replicates pretty much " real-time " meaning within seconds/minutes let me know .
Because PGPOOL-II just is n't cutting it .</tokentext>
<sentencetext>Replication, Replication, Replication....

Here's the deal.
Our software runs just fine on PostgreSQL, however if our datacenter goes down or a disaster hits, I need to have that data in multiple places at once.
I can't be running queries through a Master node across a continent and then replicate to slaves.
This is the big problem with RDBMS.
How to replicate efficiently and quickly without sacrificing performance.
Cassandra seems to be a solution that works and works well.
I probably will never be a Facebook fielding 100,000 queries per second to a 500TB database,but I do need to replicate efficiently.
Any Key/Value store allows this.
I'm interested to see how other replicate their databases.
I however don't want to hear, "Just do a nightly dump and then you have backup" or anything like that.
I want to hear a valid, good solution to replication.
If there is a database that uses SQL for it's query language that as microsecond query times in a huge database that replicates pretty much "real-time" meaning within seconds/minutes let me know.
Because PGPOOL-II just isn't cutting it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650386</id>
	<title>Re:I'm Still Fuzzy on NoSQL</title>
	<author>ishobo</author>
	<datestamp>1269771420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Unfortunately the NoSQL people should have called their movement "nonrelational". You can have a relational database and not use SQL; the two are not dependent on each other as there are nonrelational databases that allows the use of SQL. Although the movement for the use of nonrelational databases may be new, the use of nonrelationals is not. My first exposre to a business class database was Pick in the 70s. There are plenty of these types of systems in use today. Nonrelationals have been going strong for over 40 years</p><p>This article is another case of somebody that does not have the breadth of experience in the field. The same applies to the the people that started this movement. I have to ask, does college no longer teach the history of computing?</p></htmltext>
<tokenext>Unfortunately the NoSQL people should have called their movement " nonrelational " .
You can have a relational database and not use SQL ; the two are not dependent on each other as there are nonrelational databases that allows the use of SQL .
Although the movement for the use of nonrelational databases may be new , the use of nonrelationals is not .
My first exposre to a business class database was Pick in the 70s .
There are plenty of these types of systems in use today .
Nonrelationals have been going strong for over 40 yearsThis article is another case of somebody that does not have the breadth of experience in the field .
The same applies to the the people that started this movement .
I have to ask , does college no longer teach the history of computing ?</tokentext>
<sentencetext>Unfortunately the NoSQL people should have called their movement "nonrelational".
You can have a relational database and not use SQL; the two are not dependent on each other as there are nonrelational databases that allows the use of SQL.
Although the movement for the use of nonrelational databases may be new, the use of nonrelationals is not.
My first exposre to a business class database was Pick in the 70s.
There are plenty of these types of systems in use today.
Nonrelationals have been going strong for over 40 yearsThis article is another case of somebody that does not have the breadth of experience in the field.
The same applies to the the people that started this movement.
I have to ask, does college no longer teach the history of computing?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648214</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269798720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yep.  I used to work at a place that did
network analysis.  There were huge volumes of
data (think, something about almost every packet).
We tried SQL based solutions.  There was no way
we could shoehorn it on the hardware.  The solution
was an in-house DB with only the thinnes veneer of
SQL for the web front end.  Almost certainly, the
in-house DB wasn't proper SQL, but because it
was custom, the non-SQL aspects were known.  It
fixed the problem.</p></htmltext>
<tokenext>Yep .
I used to work at a place that did network analysis .
There were huge volumes of data ( think , something about almost every packet ) .
We tried SQL based solutions .
There was no way we could shoehorn it on the hardware .
The solution was an in-house DB with only the thinnes veneer of SQL for the web front end .
Almost certainly , the in-house DB was n't proper SQL , but because it was custom , the non-SQL aspects were known .
It fixed the problem .</tokentext>
<sentencetext>Yep.
I used to work at a place that did
network analysis.
There were huge volumes of
data (think, something about almost every packet).
We tried SQL based solutions.
There was no way
we could shoehorn it on the hardware.
The solution
was an in-house DB with only the thinnes veneer of
SQL for the web front end.
Almost certainly, the
in-house DB wasn't proper SQL, but because it
was custom, the non-SQL aspects were known.
It
fixed the problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650772</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Anonymous</author>
	<datestamp>1269774000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>According to this link: <a href="http://www.americanwaymag.com/new-york-stock-exchange-gordon-charlop-robert-mccooey-jr-trading-floor-technology" title="americanwaymag.com" rel="nofollow">http://www.americanwaymag.com/new-york-stock-exchange-gordon-charlop-robert-mccooey-jr-trading-floor-technology</a> [americanwaymag.com] </p><p>Your scale estimates are bull crap. That is roughly 46 transactions a minute. Twitter does 600 TPS as of two months ago and is growing at \%15 per month so its likely much higher now. According to the <a href="http://www.twitpocalypse.com/" title="twitpocalypse.com" rel="nofollow">Twitpocalypse</a> [twitpocalypse.com] guys they go over 800 tweets per second during a normal weekday. That is over an order of magnitude different than the largest stock exchange in the world.</p></htmltext>
<tokenext>According to this link : http : //www.americanwaymag.com/new-york-stock-exchange-gordon-charlop-robert-mccooey-jr-trading-floor-technology [ americanwaymag.com ] Your scale estimates are bull crap .
That is roughly 46 transactions a minute .
Twitter does 600 TPS as of two months ago and is growing at \ % 15 per month so its likely much higher now .
According to the Twitpocalypse [ twitpocalypse.com ] guys they go over 800 tweets per second during a normal weekday .
That is over an order of magnitude different than the largest stock exchange in the world .</tokentext>
<sentencetext>According to this link: http://www.americanwaymag.com/new-york-stock-exchange-gordon-charlop-robert-mccooey-jr-trading-floor-technology [americanwaymag.com] Your scale estimates are bull crap.
That is roughly 46 transactions a minute.
Twitter does 600 TPS as of two months ago and is growing at \%15 per month so its likely much higher now.
According to the Twitpocalypse [twitpocalypse.com] guys they go over 800 tweets per second during a normal weekday.
That is over an order of magnitude different than the largest stock exchange in the world.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652994</id>
	<title>Re:Some people just want the holy grail</title>
	<author>ceoyoyo</author>
	<datestamp>1269794520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>True, and occasionally people actually do that.  OOs biggest feature though, is that it forces you to <i>organize</i> your code.  You have to think about partitioning functional bits off into different objects and you have to think about the interfaces for those objects.  It forces you to design modular code with defined ways for different modules to interact.  It's nothing you can't do in a non OO language, but OO forces you to do it.</p></htmltext>
<tokenext>True , and occasionally people actually do that .
OOs biggest feature though , is that it forces you to organize your code .
You have to think about partitioning functional bits off into different objects and you have to think about the interfaces for those objects .
It forces you to design modular code with defined ways for different modules to interact .
It 's nothing you ca n't do in a non OO language , but OO forces you to do it .</tokentext>
<sentencetext>True, and occasionally people actually do that.
OOs biggest feature though, is that it forces you to organize your code.
You have to think about partitioning functional bits off into different objects and you have to think about the interfaces for those objects.
It forces you to design modular code with defined ways for different modules to interact.
It's nothing you can't do in a non OO language, but OO forces you to do it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648354</id>
	<title>Rails "marginalized" by NoSQL?</title>
	<author>SanityInAnarchy</author>
	<datestamp>1269799800000</datestamp>
	<modclass>None</modclass>
	<modscore>2</modscore>
	<htmltext><p>Bullshit.</p><p>ActiveRecord? Definitely. Rails as a whole? You might consider replacing it with another Ruby framework, but the same ideas are going to apply. Remember how Rails and Merb are merging? Merb tends to be ORM-agnostic, but the recommended Merb stack suggested DataMapper, which does support a few NoSQL databases.</p><p>Even if you needed a different ORM per NoSQL database, it wouldn't marginalize Rails as a whole, but that simply isn't the case. Just use DataMapper, then plug in the flavor of the day.</p><p>As an example, Rails (and DataMapper) <a href="http://appengine-jruby.googlecode.com/" title="googlecode.com">run on Google App Engine</a> [googlecode.com].</p></htmltext>
<tokenext>Bullshit.ActiveRecord ?
Definitely. Rails as a whole ?
You might consider replacing it with another Ruby framework , but the same ideas are going to apply .
Remember how Rails and Merb are merging ?
Merb tends to be ORM-agnostic , but the recommended Merb stack suggested DataMapper , which does support a few NoSQL databases.Even if you needed a different ORM per NoSQL database , it would n't marginalize Rails as a whole , but that simply is n't the case .
Just use DataMapper , then plug in the flavor of the day.As an example , Rails ( and DataMapper ) run on Google App Engine [ googlecode.com ] .</tokentext>
<sentencetext>Bullshit.ActiveRecord?
Definitely. Rails as a whole?
You might consider replacing it with another Ruby framework, but the same ideas are going to apply.
Remember how Rails and Merb are merging?
Merb tends to be ORM-agnostic, but the recommended Merb stack suggested DataMapper, which does support a few NoSQL databases.Even if you needed a different ORM per NoSQL database, it wouldn't marginalize Rails as a whole, but that simply isn't the case.
Just use DataMapper, then plug in the flavor of the day.As an example, Rails (and DataMapper) run on Google App Engine [googlecode.com].</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31655642</id>
	<title>What?</title>
	<author>C\_Kode</author>
	<datestamp>1269869820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I wrote this guy off the second he mentioned Walmart's database.  How Walmart uses databases vs Facebook or Twitter is completely different.  I'm pretty sure Walmart doesn't have 6 million people writing to that database at any given time.</p></htmltext>
<tokenext>I wrote this guy off the second he mentioned Walmart 's database .
How Walmart uses databases vs Facebook or Twitter is completely different .
I 'm pretty sure Walmart does n't have 6 million people writing to that database at any given time .</tokentext>
<sentencetext>I wrote this guy off the second he mentioned Walmart's database.
How Walmart uses databases vs Facebook or Twitter is completely different.
I'm pretty sure Walmart doesn't have 6 million people writing to that database at any given time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31773222</id>
	<title>NoSQL is not just for scalability,it buys you time</title>
	<author>nakubu</author>
	<datestamp>1270721820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This article seems to totally miss the point about why startups are using NoSQL databases, namely, those that are schemaless.  It's because most startups are in the process of building their main product on the fly, pushing out new versions as often as a few days or hours depending on their deployment model.  Schema stand in the way of rapid development since you have to CONSTANTLY redefine them as you redefine your product.  So updating your db goes something like this:
"Oh, I have to change this relationship from one to one to one-to-many."
"Well, now that we redesigned part of the database, let's migrate it."
"Ok, well enough time has passed. is it done yet? no? okay"
"ah, it's done, ok, take down the servers for maintenance and restart"

or, you can use something like couchdb, and just insert whatever new data you want on the fly, without defining schema, without migrations, and without downtime.  A win for startups.  It's not just about scalability, it's also about being able to do a simple task.</htmltext>
<tokenext>This article seems to totally miss the point about why startups are using NoSQL databases , namely , those that are schemaless .
It 's because most startups are in the process of building their main product on the fly , pushing out new versions as often as a few days or hours depending on their deployment model .
Schema stand in the way of rapid development since you have to CONSTANTLY redefine them as you redefine your product .
So updating your db goes something like this : " Oh , I have to change this relationship from one to one to one-to-many .
" " Well , now that we redesigned part of the database , let 's migrate it .
" " Ok , well enough time has passed .
is it done yet ?
no ? okay " " ah , it 's done , ok , take down the servers for maintenance and restart " or , you can use something like couchdb , and just insert whatever new data you want on the fly , without defining schema , without migrations , and without downtime .
A win for startups .
It 's not just about scalability , it 's also about being able to do a simple task .</tokentext>
<sentencetext>This article seems to totally miss the point about why startups are using NoSQL databases, namely, those that are schemaless.
It's because most startups are in the process of building their main product on the fly, pushing out new versions as often as a few days or hours depending on their deployment model.
Schema stand in the way of rapid development since you have to CONSTANTLY redefine them as you redefine your product.
So updating your db goes something like this:
"Oh, I have to change this relationship from one to one to one-to-many.
"
"Well, now that we redesigned part of the database, let's migrate it.
"
"Ok, well enough time has passed.
is it done yet?
no? okay"
"ah, it's done, ok, take down the servers for maintenance and restart"

or, you can use something like couchdb, and just insert whatever new data you want on the fly, without defining schema, without migrations, and without downtime.
A win for startups.
It's not just about scalability, it's also about being able to do a simple task.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651494</id>
	<title>Re:Price may favor noSQL for some applications</title>
	<author>ducomputergeek</author>
	<datestamp>1269779100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are different databases for different tasks.  Teradata produces a damn good database, but it's primarily for data wearhousing and BI tasks.  That being said, they now have a version that will run up to 1TB (I believe it's 1TB) available Free.  Just like IBM has their DB2 Express-C edition for free as well.  Both have suited our tasks for development work just fine.</p><p>However, PostgreSQL 9 is supposed to have native replication/clustering/Hot Standby.  Which would address my concerns with using the database in mission critical databases that aren't dealing with large datasets.</p></htmltext>
<tokenext>There are different databases for different tasks .
Teradata produces a damn good database , but it 's primarily for data wearhousing and BI tasks .
That being said , they now have a version that will run up to 1TB ( I believe it 's 1TB ) available Free .
Just like IBM has their DB2 Express-C edition for free as well .
Both have suited our tasks for development work just fine.However , PostgreSQL 9 is supposed to have native replication/clustering/Hot Standby .
Which would address my concerns with using the database in mission critical databases that are n't dealing with large datasets .</tokentext>
<sentencetext>There are different databases for different tasks.
Teradata produces a damn good database, but it's primarily for data wearhousing and BI tasks.
That being said, they now have a version that will run up to 1TB (I believe it's 1TB) available Free.
Just like IBM has their DB2 Express-C edition for free as well.
Both have suited our tasks for development work just fine.However, PostgreSQL 9 is supposed to have native replication/clustering/Hot Standby.
Which would address my concerns with using the database in mission critical databases that aren't dealing with large datasets.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648134</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648570</id>
	<title>Re:The Article Is Right... And Wrong</title>
	<author>Tablizer</author>
	<datestamp>1269801300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Perhaps some are afraid that the No-Sql movement will <b>leak into other niches out of hype</b>. After all, OOP leaked out of physical modeling and into other niches without being fully tested for those niches, and people started clamoring for OODBMS. (I'm of the opinion that "everything OOP" is a no-no. Use it where it helps, but not where it doesn't.)</p></htmltext>
<tokenext>Perhaps some are afraid that the No-Sql movement will leak into other niches out of hype .
After all , OOP leaked out of physical modeling and into other niches without being fully tested for those niches , and people started clamoring for OODBMS .
( I 'm of the opinion that " everything OOP " is a no-no .
Use it where it helps , but not where it does n't .
)</tokentext>
<sentencetext>Perhaps some are afraid that the No-Sql movement will leak into other niches out of hype.
After all, OOP leaked out of physical modeling and into other niches without being fully tested for those niches, and people started clamoring for OODBMS.
(I'm of the opinion that "everything OOP" is a no-no.
Use it where it helps, but not where it doesn't.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648134</id>
	<title>Price may favor noSQL for some applications</title>
	<author>cervo</author>
	<datestamp>1269798180000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Many of the NoSQL sources scale better than a normal database and are available cheap.  Oracle costs a fortune, and if you want to run Oracle on a cluster good luck.  They also don't let you publish benchmarks without their permission.  But most people I know who use Oracle claim it totally beats everything else (without further clarification).  DB2 includes a cluster edition that is also quite good.  It uses a shared nothing architecture.  But none of these solutions are free.  Also teradata is also cited as a good parallel database.  If you are a start-up and your choice is a NoSQL solution that is almost free or 100,000+ for some commercial parallel database, which do you go to?<br> <br>
But no matter what you will consume resources with a relationship database on ensuring consistency (which many times is what you want but not 100\% of the time).  Amazon's Dynamo works by not caring so much about consistency and trading consistency for availability of the overall service.  For a shopping cart it is fine, but you wouldn't want to do your credit card processing using it.  Google's GFS is optimized to do the file operations that google does the most.  However there was an article in the ACM not that long ago comparing Map Reduce (Hadoop's implementation) against two parallel databases, and it lost.  OF course the Parallel Databases were all not free....and hadoop is....
<br> <br>
So overall I'd say the decision comes down to price mostly (as it does with most startups).  If you can make do with one server than sure do PostgreSQL (or mySQL...although they always tried to force licensing for commercial products even though it is GPL...).  If you need a cluster, both have clustering solutions, but as far as I can tell they are not as good as the commercial Parallel databases.  If you have lots of money then sure go with Oracle, it seems through word of mouth Oracle is the best for both parallel and stand alone in terms of performance.  DB2 was good enough for a former job.  They had terabytes in the mid 1990's using about 20 servers.  Now that the hardware is much better I'm sure it scales even better....  But if money is a consideration, then go with an open source noSQL solution.  A lot of people now swear by Cassandra, I haven't had a chance to check it out yet.</htmltext>
<tokenext>Many of the NoSQL sources scale better than a normal database and are available cheap .
Oracle costs a fortune , and if you want to run Oracle on a cluster good luck .
They also do n't let you publish benchmarks without their permission .
But most people I know who use Oracle claim it totally beats everything else ( without further clarification ) .
DB2 includes a cluster edition that is also quite good .
It uses a shared nothing architecture .
But none of these solutions are free .
Also teradata is also cited as a good parallel database .
If you are a start-up and your choice is a NoSQL solution that is almost free or 100,000 + for some commercial parallel database , which do you go to ?
But no matter what you will consume resources with a relationship database on ensuring consistency ( which many times is what you want but not 100 \ % of the time ) .
Amazon 's Dynamo works by not caring so much about consistency and trading consistency for availability of the overall service .
For a shopping cart it is fine , but you would n't want to do your credit card processing using it .
Google 's GFS is optimized to do the file operations that google does the most .
However there was an article in the ACM not that long ago comparing Map Reduce ( Hadoop 's implementation ) against two parallel databases , and it lost .
OF course the Parallel Databases were all not free....and hadoop is... . So overall I 'd say the decision comes down to price mostly ( as it does with most startups ) .
If you can make do with one server than sure do PostgreSQL ( or mySQL...although they always tried to force licensing for commercial products even though it is GPL... ) .
If you need a cluster , both have clustering solutions , but as far as I can tell they are not as good as the commercial Parallel databases .
If you have lots of money then sure go with Oracle , it seems through word of mouth Oracle is the best for both parallel and stand alone in terms of performance .
DB2 was good enough for a former job .
They had terabytes in the mid 1990 's using about 20 servers .
Now that the hardware is much better I 'm sure it scales even better.... But if money is a consideration , then go with an open source noSQL solution .
A lot of people now swear by Cassandra , I have n't had a chance to check it out yet .</tokentext>
<sentencetext>Many of the NoSQL sources scale better than a normal database and are available cheap.
Oracle costs a fortune, and if you want to run Oracle on a cluster good luck.
They also don't let you publish benchmarks without their permission.
But most people I know who use Oracle claim it totally beats everything else (without further clarification).
DB2 includes a cluster edition that is also quite good.
It uses a shared nothing architecture.
But none of these solutions are free.
Also teradata is also cited as a good parallel database.
If you are a start-up and your choice is a NoSQL solution that is almost free or 100,000+ for some commercial parallel database, which do you go to?
But no matter what you will consume resources with a relationship database on ensuring consistency (which many times is what you want but not 100\% of the time).
Amazon's Dynamo works by not caring so much about consistency and trading consistency for availability of the overall service.
For a shopping cart it is fine, but you wouldn't want to do your credit card processing using it.
Google's GFS is optimized to do the file operations that google does the most.
However there was an article in the ACM not that long ago comparing Map Reduce (Hadoop's implementation) against two parallel databases, and it lost.
OF course the Parallel Databases were all not free....and hadoop is....
 
So overall I'd say the decision comes down to price mostly (as it does with most startups).
If you can make do with one server than sure do PostgreSQL (or mySQL...although they always tried to force licensing for commercial products even though it is GPL...).
If you need a cluster, both have clustering solutions, but as far as I can tell they are not as good as the commercial Parallel databases.
If you have lots of money then sure go with Oracle, it seems through word of mouth Oracle is the best for both parallel and stand alone in terms of performance.
DB2 was good enough for a former job.
They had terabytes in the mid 1990's using about 20 servers.
Now that the hardware is much better I'm sure it scales even better....  But if money is a consideration, then go with an open source noSQL solution.
A lot of people now swear by Cassandra, I haven't had a chance to check it out yet.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647896
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648126
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653236
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647896
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651494
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648134
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648306
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648248
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649640
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647880
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648570
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652316
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648134
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650360
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650386
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648234
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31661186
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652042
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648444
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31661050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648372
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650772
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648326
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652740
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648306
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648658
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649796
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652994
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651410
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648078
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653484
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653326
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648068
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648680
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648304
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650302
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650532
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31729282
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_1432234_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650180
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648068
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31663192
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648334
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649906
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647850
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648444
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652042
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648326
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650772
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649966
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648874
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650532
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653484
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653908
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648570
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649796
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648372
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647880
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31649640
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647906
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31729282
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648248
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648196
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648078
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650386
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647886
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648304
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648070
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650360
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652994
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648658
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650388
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648680
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648126
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31661050
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651410
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648068
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653326
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650180
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652682
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648294
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648332
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652148
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652740
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648724
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648008
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651804
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647896
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648436
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31653236
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647550
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650398
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648048
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31661186
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651574
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31650302
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31647902
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648020
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_1432234.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31648134
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31651494
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_1432234.31652316
</commentlist>
</conversation>
