Oracle
Since you mentioned Oracle just for a headline why not actually google "Oracle NoSQL" and see what Oracle has to offer in that space, you might be very surprised.
Another month, another series of gains by NoSQL databases on their relational database peers. In fact, according to the September data from DB-Engines, we’re not far away from seeing a NoSQL database crack the top three databases globally. So, for those who “can’t wait for NoSQL to die,” they’re going to be waiting a long, …
It does virtually nothing out of the box - its just a glorified key value data store with a javascript engine thrown in for roll-your-own query code. If I want to code imperatively over flat file or JSON style data I don't need an entire DB system to do it. Plus on our test system it managed to crash while idling after having a few weeks uptime! Also it might help if they had half decent documentation for their APIs.
Personally I can't stand Oracle with their half baked subsidiary products, their treating customer issues as an inconvenience that gets in the way of the cheques and their take-the-piss pricing. However what I do like is the SQL language and I'll take that anyday for doing complex data searches over the amateur hour efforts that the noSQL people chuck over the fence.
So quite a lot like SQL databases in their formative years, then. I cut my teeth as an Oracle developer and DBA, and find their product set overpriced and confusing, in fact, if I can think of a reason not to use Oracle, I will.
It amuses me when dealing with sales people from Mongo, Neo, Couchbase, et al. that they seem to believe that their products are suitable for all situations, much like Oracle, but of course us grizzled old professionals actually realise that it's rubbish. In fact a modicum of research into database selection will tell you just when and why you should use one database over another, they all have their strengths and weaknesses.
Remember, not Only SQL is the technology du jour, a panacea for all the ills of the RDBMS market, adoption will lower your costs, and improve your prowess. Well maybe, but like all new technologies, the costs of migration, and loss of functionality may never be recoverable, against those Oracle support fee savings that are ripe for attack, when cost cutting comes around.
NoSQL, buyer beware, be very aware of what you are actually buying. RDBMS solutions are now pretty good generic solutions that sparkle in a few areas. NoSQL is not generic, and will sparkle in a specific area, way and above anything an RDBMS can achieve, move away from that and you can look forward to lots of pain.
One of the reasons to bone up on PostgreSQL and MySQL skills, get 'em tacked on to the Oracle/SQLServer core skills. PG and MySQL are like "Oracle Lite", if you have more than a few years with the big boys toys then learning PG/MySQL is a doddle.
I'm learning those two plus a couple of the NoSQL products, just to keep the CV fresh. I have to agree though, most NoSQL stuff just seems to be huge scalable, glorified K/V storage apps. I know the reality is a bigger picture but it's about horses for courses. As poster above says though, there's too many muppets out there who simply think any particular DB software app is a one-size-fits-all situation, sadly they have the purse strings and we all have dance to their moronic tunes if we want to keep a wage coming in.
There is so much wrong with this article I don't know why El Reg pay Matt Asay.
1 - Look at the scale on the graph - its ~logarithmic. In 2.5 years Mongo has done a ~200 point jump - SQL server seems to be about the 1500 point mark giving a 1200 point gap - which means at the current rate it will take 15 more years to achieve parity (1200/(200/2.5)
2. Nosql <> big data - most mongo installs I know about are tiddlers - internal intranet apps and the like.
3. Oracle have already bought into NoSQL in multiple ways. (Berkelydb)
SQL is obsolete and dead.
For instance, there are two sentences:
a) ‘Pickwick!’
b) 'That, with the view just mentioned, this Association has taken into its serious consideration a proposal, emanating from the aforesaid, Samuel Pickwick, Esq., G.C.M.P.C., and three other Pickwickians hereinafter named, for forming a new branch of United Pickwickians, under the title of The Corresponding Society of the Pickwick Club.'
Evidently, that the ' Pickwick' has different importance into both sentences, in regard to extra information in both. This distinction is reflected as the phrases, which contain 'Pickwick', weights: the first has 1, the second – 0.11; the greater weight signifies stronger emotional ‘acuteness’; where the weight refers to the frequency that a phrase occurs in relation to other phrases.
SQL does not see and cannot produce the above statistics – SQL is obsolete and out of business.
Oracle and all IT Industry - IBM, Amazon, HP, all - use SQL.
I'd say that, as NoSQL is desperately scrabbling to get SQL build in the people who NoSQL are slowly learning about databases and realising that they are re-inventing the wheel. The sort of data-mining I've seen has always been possible with SQL or (in Posix case) just from the command line. NoSQL - like many computer innovations is realising that it has to do the things that it was created to avoid doing.
You canne break the laws of mathematics captain.
"SQL does not see and cannot produce the above statistics – SQL is obsolete and out of business."
You clearly have next to no idea of what relational databases are used for , probably because you've never worked in any medium to large company. When you've got some experience under your belt and have more than just a few academic examples of simple text anaysis (which has been done for decades btw) to show off, get back to us.
I have been tracking NoSQL databases for several years, collecting publicly available data on skills and vendors. The NoSQL market is still tiny. Considerations and summary of data in Section 2 of this very large slide deck: https://speakerdeck.com/abchaudhri/considerations-for-using-nosql-technology-on-your-next-it-project-1 Slides regularly updated with new data as I find it.
Martin Fowler's got a thing or two to say on this topic (e.g. https://www.youtube.com/watch?v=qI_g07C_Q5I ). Worth a look if you want to put the hype into perspective. He believes the world is heading towards what he calls "polyglot persistence" - which is just his way of saying the same as some others here - "horses for courses". NoSQL's got its place but (surprise surprise) it's just another approach with its own pros and cons.
By the way, recent versions of some "traditional" existing RDBMSs are also NoSQL stores, so you can also have the best of both worlds while only having to manage one type of database in terms HA, backups, DR, licenses, upgrades etc. - also worth thinking about.
SQL that is.
It isn't one of these hot new flash in the pan javascript frameworks that comes out in a blaze of glory and fades quickly as everyone shifts to new shiny object javascript framework thats been released. There is way too much legacy for it to be going anyway. Didnt the same thing get levelled at COBOL/CICS in the 90s? still alive and well I hear.
Mind you this worries me: *As DataStax’s Scott Hirleman told me: “NoSQL databases enable companies to be more agile, especially while deploying new features; more flexible (store varied and/or complex data types); and able to support scale without high costs and complexity.”*
O fuck, so not only do we have the current situation where intelligent, rational IT devs completely lose their mind by being 'agile', i.e. making stuff up as they go along, because the client hasn't a fucking clue what they want and causing project delays and having to re-write code, let's double whammy that by altering the schema only a daily basis so it breaks the front end code or the ORM is working overtime re-generating all the mappings!
Get a job in IT, and be a part of the nut house.
Relational databases were born it of a brilliant insight by a brilliant mathematician that hierachical data strutures were only useful for a limited single purpose and that real world problems required a more subtle and flexible approach.
While it may seem obvious to store an order a customer -> product -> qty + price. This only works for some parts of an organisation. The brand manager who wants to know how well his product is doing must perform a complex apps can on every hierarchy, the same for the warehouse manager who needs to no what to reorder.
In spite of the fact that SQL is an appallingly bad implementation of relational algebra relational databases have done an excellent job for the last 30 years and will continue to do so.
On the other hand no SQL databases were developed by people who just wanted fast acces to a lot if cute puppy pictures and were too lazy to lookup BLOB. ( not true -- but it's the impression a lot of there cheerleaders give :-). ).