Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

NoSQL Is Not Everywhere Expand / Collapse
Author
Message
Posted Monday, September 20, 2010 9:01 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 7:24 AM
Points: 31,161, Visits: 15,608
Comments posted to this topic are about the item NoSQL Is Not Everywhere






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #989883
Posted Monday, September 20, 2010 10:37 PM


Default port

Default portDefault portDefault portDefault portDefault portDefault portDefault portDefault port

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 4:53 AM
Points: 1,433, Visits: 1,845
I believe "NoSQL" can be used for "Service-only" offerings (Examples can be application/widgets that simply gather data by crawling across the web and display the same - the WeatherBug and Exchange Rate reference boards for example) that process data, but do not store it.
If they store data it may not be SQLServer or RDBMS (may be just a flat-file), but they will then have some Query language involved in data extraction and loading.
I would say that where data is involved, some query language is also involved.


Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Be courteous. Drive responsibly.

Follow me on
Twitter: @sqltwins
Google Plus: +Nakul
Post #989911
Posted Tuesday, September 21, 2010 2:09 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, October 6, 2014 12:06 PM
Points: 2,907, Visits: 1,831
I've done a lot of reading around NoSQL. First of all it stands for Not Only SQL and not NO SQL!

There are a number of NoSQL solutions who claim to be web scalable but when you dig under the covers not so many are. It's worth looking at Simon Munro's blog on the subject. Simon spoke well at the SQL Bits conference in London earlier this year.

The premise of NoSQL is that for applications where data loss is not the end of the world then the overhead of an RDBMS is overkill. They work on the principle of BASE rather than ACID (Basically Available, Soft state, Eventually Consistent).

Quest software are even releasing a version of TOAD that can talk to cloud DBs and some NoSQL contenders.

Where NoSQL is particularly useful is for complex web forms processing where a customer can ping back and forth through the user journey to suit themselves. You really wouldn't want to be trying that with a relational schema as it would require loads of nullable fields and a lot of update statements.

Until the form is completed there is no need to commit the data to an RDBMS. Service interruptions are rare enough that a missed form is not the end of the world. If we committed data into an RDBMS then such service interruptions would result in orphaned data and other data quality issues.

At present the NoSQL solutions I have seen are very much programmers databases rather than everymans databases though TOAD should at least be a step on the right path.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #990031
Posted Tuesday, September 21, 2010 5:40 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
Steve, if you worked with some of the people I have in my job history you would be disappointed a lot.

The truth is any "great next best think" is only as good as the people who construct it. Classic garbage in garbage out. There are times when the product is poor, but there are many more times when the people are poor.


<><
Livin' down on the cube farm. Left, left, then a right.
Post #990148
Posted Tuesday, September 21, 2010 7:57 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 7:58 AM
Points: 1,979, Visits: 660
Steve:

As an ex-COBOL analyst and IBM360 JCL writer, I appreciate your final comments in the article. It has been said many, many times that COBOL is old hat and will die....Long live COBOL....even tho I've cut the cord and gone with SQL, VB.Net and many other client server applications and tools in my current labors.
While it is great to be able to use or try new products, there are times when the "cost" of learning a new technology is many times more expensive than doing the same task with aged processes or languages. When was the last time anyone wrote a DOS batch file? For me, about two months ago to handle a remote process on another server. Some technologies will never die.
Post #990300
Posted Tuesday, September 21, 2010 8:10 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, October 6, 2014 12:06 PM
Points: 2,907, Visits: 1,831
When was the last time anyone wrote a DOS batch file?

About 10 minutes ago. I use them quite a bit for tweaking continuous integration and deployment scripts.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #990320
Posted Tuesday, September 21, 2010 8:40 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, February 21, 2014 8:14 AM
Points: 194, Visits: 255
Hi Steve,

On the comment you made about hoping an architect doesn't disclude something because it is new ... we do this all of the time due to risk. You analyze the new-ness of a technology and make the determination (hopefully using a standardized methodology). If it is too far outside your comfort level or provides complexities that timing will not allow, you use a "more trusted" technology.

The Digg video points out that some of their go live issues were with the Cassandra code. It doesn't point out that they came up due to the newness of the technology, but if the system had been implemented in a larger instance or had been stress tested to a higher capacity, it would probably have shown some of the inconsistencies with data corruption. They made a choice in their implementation to be on the bleeding edge and they paid for it with 1000 cuts.

Regards,
Joe
Post #990360
Posted Tuesday, September 21, 2010 9:10 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 7:28 AM
Points: 1,703, Visits: 4,839
David.Poole (9/21/2010)

The premise of NoSQL is that for applications where data loss is not the end of the world then the overhead of an RDBMS is overkill. They work on the principle of BASE rather than ACID (Basically Available, Soft state, Eventually Consistent).

I guess it's not the end of the world if a teenage girl's latest facebook post gets lost in the nightly data defrag shuffle (although she'd certainly disagree), but this BASE concept doesn't sound like something the financial, healthcare, or eCommerce industries would find beneficial to their core operations.
Post #990408
Posted Tuesday, September 21, 2010 9:27 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 598, Visits: 3,816
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.

Now I've staked my career on SQL Server, so don't just jump all over me. But I've seen this point brought up elsewhere and wondered how bad it would be to just use flat tables. All the other software may not be dead, but it is bloated! Why not databases too? Summary tables could be created on the side too, which of course helps performance.

Video graphics cards work in a brute force, but kind of a dumb way. But they do work - right?

Someone respectfully prove me wrong. Please. (Because frankly, I'm a little worried.)





______________________________________________________________________
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
Post #990436
Posted Tuesday, September 21, 2010 9:43 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 7:24 AM
Points: 31,161, Visits: 15,608
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.


Perhaps that was some of the driving force, though I think that the ACID properties weren't available in flat files either.

These days we're going back to XML sometimes and that's almost like scanning a flat file in many instances.

Not sure about graphic cards. I know there have been some improvements over time, moving to new algorithms, but not sure about the brute force storing all pixels inside them.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #990461
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse