As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

The screwdriver did not replace the hammer, though the main purpose of both is to hold things together. NoSQL and relational DBs are two different tools for two different jobs.
–
webbiedaveOct 25 '10 at 21:40

2

Short of it is that we now have the hammer (file system), the screwdriver (RDBMS), and the wrench (NoSQL).
–
MIADec 29 '10 at 18:16

This could be off-topic. If you didn't commit for the DBA proposal, wait until next week to post this question on dba.stackexchange.com
–
bigownJan 4 '11 at 18:03

What will happen is that all fancy and useful new features are going to be integrated into the SQL language, which isn't strictly about relational databases. SQL has already integrated OLAP (star schema) and can deal with column stores ("NewSQL"). So, while NoSQL is often referred to as meaning "Not Only SQL", it will really evolve into "No, SQL" ;-)
–
Lukas EderDec 15 '13 at 8:45

8 Answers
8

I don't think so. Basically most of the NoSQL solutions seem to store key value pairs more or less. If you want to report on something, it is much easier to join a few tables together then to figure out how to string a whole bunch of key value pairs together. Also many of the products have their own API so the skills don't translate as well as SQL. Whether someone uses DB2, Oracle, PostgreSQL, MySQL, Mimer, SQL Server, etc. the general syntax of SQL is similar and the subset of ANSI SQL will work. Then you just need to pick up a few particulars. With the NoSQL solutions, just because you know how to use Hadoop and MapReduce does not mean that you can pick up Pig Latin in a day or two and use that....

Also with line of businesses, a big deal is the reporting. If NoSQL makes this harder, then it won't fly. In most companies information is power and there is huge value in being able to efficiently share that information. Basically you want the sales transactions to go into some type of data store where users can run reports, data mine, etc. to slice/dice/analyze that sales data and figure out corporate strategy.

One of the chief advantages of NoSQL now is price. Both DB2 and Oracle have shared nothing architectural solutions (I can't speak for Oracle but DB2 has had theirs since before 1999 and it worked pretty well at the time). But these cost a fortune in licensing costs. The advantage with Hadoop is that there are no licensing costs. Buy your 20 computers, download it, and go....Or just buy some Amazon Web Services instances, install a Linux image and use Hadoop to get going there...The Linux image that would enable you to use Hadoop is much cheaper than just the windows operating system on Amazon (without even the cost for SQL Server or Oracle).

Also NoSQL can be simpler for the programmer. There is no need to figure out a table structure in advanced to structure your data. Also you don't need to work hard to map your objects to the table structure, you can just store them as key value pairs. On the other side, these two advantages make it harder to report on. If you use not well defined structures, this presents challenges on trying to read the data later to report on. Also if the format is convenient for the program, you will spend a lot of time figuring out how to report on it as well. Nevertheless if you need to get a product out the door yesterday, the time saved might matter....

I think that NoSQL solutions are basically one more tool in our toolbox. And also they might force the open source database makers to focus more on scaling and shared nothing approaches. Probably we will see some of the more popular features make their way into relational database systems over time... This is similar to the way that a lot of relational databases now have data types and extensions for dealing with XML data while there was once talk of XML databases replacing relational databases. Now where are the XML databases? And yet the relational databases still remain in power....

Why is cost such a big deal for NoSQL? Plenty of SQL databases are free. You don't have to use Oracle or MSSQL.
–
alternativeOct 24 '10 at 0:22

3

But not many SQL databases that scale properly are free. Also some of the vendors charge extra on clustering to enable scaling out.
–
CervoOct 29 '10 at 3:18

which free SQL databases would you consider to scale well?
–
user1249Dec 29 '10 at 19:47

2

MySQL claims to be able to scale mysql.com/why-mysql/scaleout/booking.html. Here's a thread on the issue at serverfault.com serverfault.com/questions/204700/…. Also from what I have seen, people have gotten PostgreSQL to scale mostly using custom solutions. Basically both are way behind Oracle/DB2's scaling and even MS SQL Server now has some support for horizontal scaling.
–
CervoFeb 21 '11 at 14:39

Will the equation 2+2=4 be outdated and replaced by 2+2 > 4 or 2+2 < 4 ... any time soon ??
The Relational model is not just a technology. Its based on Relational Calculus and Relational Algebra... whose foundation is the very heart of mathematics : The Set Theory.
The operations like filtering, joins, projections ... on relational data that SQL exposes are not mere system calls. They are in league with addition , subtraction, multiplication etc.
File systems might be replaced by some other storage abstraction, object oriented programming might be superseded by some X oriented programming paradigm, even the very act of computer programming itself might not be there but forget about mathematics being out dated for at least a hundred years from now.

Still, don't forget that in the past when people needed a logarithm or value for sine, they would look them up in tables. Now the calculator/computer implements numerical methods to evaluate the equations on the spot (sometimes even evaluating the power series...). Also as people find new ways of doing things the old fall out. E.g. would you use the trapezoid rule to compute a numerical integral, or would you use Simpson's rule... For testing primes you'd probably use Fermat's primality test.
–
CervoMay 7 '11 at 21:00

NoSQL puts the burden of managing your data directly upon the programmer to work with the information primitives whatever NoSQL database provides. Think of a relational database as a ready-to-use package of information management functions within its framework of storage and computation. Programming a NoSQL system is a lot like having the parts of a disassembled relational database and bolting them together into devices that provide the minimal amount of infrastructure required to implement a feature.

File systems are still here despite the existence of relational databases, so too will relational databases be here despite the existence of NoSQL databases. They're still a valuable tool for certain kinds of data. As computers get "larger" with available memory, bandwidth or disk space, there are datasets that could migrate away from NoSQL-style solutions back into relational, or perhaps, to distributed file systems that scale beyond what NoSQL or relational databases can provide.

I don't mind it as long as I'm able to retrieve the information back from its position in space. More often than not, the organization of those objects are also "separate objects floating in space." It's a matter of deciding what's important to your application, defining it and staying consistent, whether its stored in a file system, relational database or NoSQL database. Consistency makes the difference--but I'm unsure if I'm ready to try and use the MapReduce as the hammer upon everything in a NoSQL database like CouchDB does.
–
WxfzSep 19 '10 at 22:10

Not anytime in our present careers. SQL syntax may change a few more times, but the relational model is a strong one, and SQL is a sufficient API (yes I said API), and without a fundamental computational database shift, I think SQL or it's children's syntax will be here for a long time.

2008 was the last year that I was directly involved with FORTRAN (77 actually). That's like 40+ years.

There are too many NoSQL solutions for all of them to succeed. All the ones I have looked at are flawed in some way. The main issue is infrastructure, the next issue is reporting.

Right now I can hire a professional with SQL tuning expertise. There just aren't the numbers of those people with NoSQL expertise. Reporting is a mess and normally requires lots of hand written code. People will start to build JDBC drivers etc for NoSQL and suddenly they will look like ... databases.

What NoSQL will do though is to force the SQL vendors to improve their products. Expect to see NoSQL style APIs work their way into major vendors products in a years time.

Oracle/Sybase/MS should embrace the NoSQL movement. It will allow them to lock people into their products with custom apis!

The lack of a defined schema is attractive when you are starting up, its a mill stone when you are consolidating code. Most developers have no idea how to build an evolvable data model and the lack of a schema will cause major issues.

Current relational databases are not purely relational but spoil relational algebra at several places (NULLs, duplicated rows etc.), so referring to the relational model to defend relational databases is no valid argument. Nevertheless relational databases are popular for good reasons. There will just be some more special types of databases or additional DBMS features to choose from. @Cervo already mentioned how XML got integrated into SQL, it was the same with object orientation and OODBMS. Because in practice "relational databases" are not truly relational, they can simply incorporate other features if needed.

Asking for SQL: I wish that it would go away, to be replaced by a standardized language. Just now it is more like a bunch of dialects and every DBMS interprets a different subset in a slightly differently way. As far as I know SQL-92 was the last standard thanks to the NIST test suite.

Relational databases will eventually fade away, and SQL will fade with them, but I do not expect this to occur any time soon. The relational database model, for all its warts and foibles, is "good enough" for many applications - it's the right-sized hammer for the nail of "how do I easily store my data". It's reasonably easy to understand and work with, and there's plenty of implementations. So if your question was an indirect way of asking "Do I really have to learn and understand SQL?" the answer is "Yes". :-)

NoSQL-databases definitely have a place in the software world. But it will take a long time, if ever, for them to replace traditional RDBMS:es. In the mean time, use them for what they're good for.

The most interesting type of NoSQL (which can mean "Not Only SQL" by the way, a much better name in my option) is the graph database where data is represented as nodes and relations (edges). It lets you model Facebook-type who-knows-who-relationships in a very efficient way.