August 27, 2015 at 12:00 am
Comments posted to this topic are about the item NOSQL and RDBMSs
August 27, 2015 at 4:05 am
That's a great article with good points and a really powerful and easy to assimilate comparison graphic David.
Thanks for sharing it.
Tim Walker
.
August 27, 2015 at 5:16 am
Sorry, but I have to ask - in the following sentence ---
I think that both the stick-in-the-mudes and fanboys have failed
That should be "muds" and not "mudes," shouldn't it?
As for the rest of the article, I'm still absorbing it. The content is quite new to me, but I certainly appreciate the effort that went into producing it.
August 27, 2015 at 5:34 am
....
In the RDBMS camp I can understand the attraction of being able to accept and process JSON and absorb other NOSQL type functionality but isn’t this precisely the one-size-fits-all approach to solutions that NOSQL solutions originally identified as a mistake?
Is it a mistake? For me there are developers who say "its simple! We write process A in python, process B in C# use Redis as a cache because really when do unix servers ever crash! and then we can then use language X for process....... then store it in a json object and we don't need a rdbms because those constraints get in the way of flexibility and we only ever process a row at a time anyway" A polygot approach that seems to do more harm than good. Seems to be the way university teaches things now 🙁
And no I don't put myself as a stick in the mud. I do enjoy progress but do balance it against is the solution good enough.
August 27, 2015 at 6:11 am
David,
Your article was very well thought out. Although I am not a Fanboy, I recognize that NoSql database applications have their use and I have recommended them on occasion. They are definitely not the panacea some think them to be. Your diagram articulated very clearly the strengths and weaknesses of NoSql. It is a very good starting point for any architectural discussion. With your permission I may use it in the future.
August 27, 2015 at 6:14 am
Really liked the way you stepped back to give an objective overview. I'm now more open to the idea of NOSQL to solve certain business issues.
August 27, 2015 at 6:33 am
To consider that some of the ideas from the RDBMS world are actually pretty good and are why the technology has thrived for so long.
It's survived and thrived so long for the simple reason that there is a solid mathematical foundation underlying relational databases and SQL. Argue about the language all you want, but you're not going to get very far arguing the math.
This isn't to say NoSQL isn't viable or useful. Like everything else database-wise, you have to look at what you're trying to do and evaluate your options based on the issues, limitations and contributions of each technology.
The failure to do the above is the real mistake both camps have made.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
August 27, 2015 at 6:42 am
I know nothing about NOSQL or most other languages. Regardless, I don't believe SQL is going away anytime soon, not before I retire anyway.
August 27, 2015 at 7:26 am
greenclay (8/27/2015)
Sorry, but I have to ask - in the following sentence ---I think that both the stick-in-the-mudes and fanboys have failed
That should be "muds" and not "mudes," shouldn't it?
As for the rest of the article, I'm still absorbing it. The content is quite new to me, but I certainly appreciate the effort that went into producing it.
I had to look this one up.
definition of "mude" - a verb meaning: change, alter; turn; vary; transfer; turn around; veer; moult; mutate
So "stick-in-the-mude" compiles and is in context; at least sort of. 🙂
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 27, 2015 at 7:36 am
I was in the camp of "Change is probably good but I need to be convinced." I had looked into NoSQL around 2012 and what I read had not convinced me; mostly because I was looking at NoSQL to replace the functionality of my RDBMS. Now we are looking at data lakes and some applications where NoSQL is a viable and strong option. I have just started learning about MongoDB and it is very interesting and I am enjoying the new way of thinking.
August 27, 2015 at 7:37 am
I like one thing, the chance to improve SQL, or maybe (horrors!) introduce QUEL,
SQL is based on relational algebra,
QUEL of Ingre and Postgres fame (and maybe other db's) is based on relational calculus, and is VERY powerful.
We used to use it for analyzing data, and found it very easy to use.
we routinely saw where QUEL could in 2 statements replace pages of SQL.
Just a thought...:-D
August 27, 2015 at 7:46 am
David.Poole (8/26/2015)
Why do we use an RDBMS for….•Web session state?
•Logging and auditing?
•Queueing applications?
That's a question I often ask a lot when someone speaks of a problem they are encountering when supporting millions of daily inserts into a table or how to model unstructured data in SQL Server. Why is this being done in a RDMS in the first place?
Recording things like mouse clicks and hover over events originating from a website is simply not transactional or operational data. Likewise forcing application developers to perist their JSON or binanary objects in a relational database is not reasonable.
For example in a eCommerce website, caching of the product catalog, session state persistance for the shopping cart, and event logging for usage statistics should all be persisted outside the RDMS. Only when the clicks finally clicks the 'Submit' button to initiate an actual sales order should the RDMS become involved.
For many of us, the new NoSQL solutions arn't a replacement for the RDMS, rather it's a replacement for XML and CSV files. It's memcaching and data dumping done better.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 27, 2015 at 8:02 am
Very interesting article. I've had my eyes opened quite a bit lately concerning NoSQL environments and I've reached the following conclusions:
1. NoSQL solutions definitely have their shining moments and all due consideration should be given to them where appropriate
2. NoSQL is NOT a replacement for RDBMS nor should it ever be considered as such.
3. A NoSQL solution is indeed the correct choice for many implementations that are currently in RDBMS (this is not in conflict with #2 above)
My dad always taught me to use the right tool for the right job. Just because you CAN use a wrench for a hammer doesn't mean that you SHOULD. An RDBMS solution is not a hammer where every problem is a nail. NoSQL should be used where appropriate just as RDBMS should be used only where appropriate.
I do take exception to the comment made in the article:
While I understand the pressure to adopt a SQL like language I do think it is a mistake to base that language too closely on SQL. I feel that basing their query language on SQL, while aiding adoption it will lead to lazy thinking by architects and developers. It will prevent the exploration of key strengths of the NOSQL platform that do not fit easily with a language based on SQL.
I don't feel that employing an SQL-like language on NoSQL is necessarily a bad thing in of itself. If the data is organized in a relational model and lends itself to set-based operations, then it doesn't necessarily matter how the functions are performed under the hood. A NoSQL database will not be as optimal as an RDBMS for relational data just like an RDBMS is not optimal for non-relational data, but that does not undermine the concept and approach. Again, it all comes down to using the right tool for the right job.
LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com
August 27, 2015 at 8:30 am
It's survived and thrived so long for the simple reason that there is a solid mathematical foundation underlying relational databases and SQL.
That is why I'm optimistic about graph databases.
August 27, 2015 at 9:19 am
Luckily I enjoyed the benefits of both worlds 🙂
As a Data Scientist I had to store real-time Tweets from the firehose (that's the Twitter service) and MongoDB worked so well to do the job I instantly loved that. But before that I was always using complex cubes and RDBMS from Microsoft Sql Server. Both technologies are perfect for the proper world. In fact we analyzed MongoDB data and stored some results in SQL because it was way better to handle it.
The problem sometimes is people became fans of something and try to stick a solution into everything when it's the opposite, we need to understand the problem to find the solution.
Great article by the way!
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply