December 6, 2017 at 8:19 pm
Comments posted to this topic are about the item The Relational Database is the Default
December 7, 2017 at 1:25 am
You know how newbies are convinced that DRI can be handled by the app? They are ALWAYS proved to be wrong. Every single time.
Its hard enough getting Data Quality right in a disciplined data repository such as an RDBMS. In MongoDB what you persist has to be a valid JSON document. That's it. You can stick your granny's fruit cake recipe in the middle of records from a flight recorder and as far as the DB is concerned that is perfectly OK.
The use case for MongoDB is when you have a rapidly evolving schema or something that requires a highly flexible schema such as a SurveyMonkey type application and possibly product catalogue management.
Most of us will never see the loads and data volumes that caused the excitement for NOSQL in the first place. I don't work for Facebook or Netflix or a company requiring high frequency trading.
The value in NOSQL is that it has forced us to revisit assumptions and identify weaknesses that need to be addressed.
1. How do we provide full text search capabilities that are genuinely useful?
2. How should we handle log data?
3. How should we handle transient data such as web sessions
4. How should we handle queueing
5. How should we handle and traverse flexible relationships where the relationship itself is as valuable as the data items participating in those relationships?
When you use different technologies to solve your problems you mustn't lose sight of the fact that your solution creates its own problems (integration for example). The problems you create may be bigger than the problems you solve
December 7, 2017 at 1:39 am
Not convinced but should put my hand up to say that I've not come across a single instance where I've needed it. Think going forward the point at which people and organisations transition to NOSQL will become larger and larger because problem cases will be increasingly solved as we transition to better hardware and improved bandwidth.
On point 5 of David's post I would argue that you can set up relational databases to have a key value format - I kind of like that format for somewhat random child records where parents can have very variable number and type of child records and my investigation of that format was brought about by trying to understand what everyone was talking about with NOSQL.
It is a very good point that the relationships in the data is as important as the data. A point that people starting out don't always get.
cloudydatablog.net
December 7, 2017 at 2:39 am
Point 5 will be addressed by evolution of the new graph capabilities of SQL Server. It's made a good start but NEO4J is quite a long way ahead
December 7, 2017 at 3:30 am
Yes! Couldn't agree more.his. All they are doing is shifting the schema to a technology not built for the purpose of schema management or in another sense 'time shifting' the schema into the future as the application/system will require one whether you recognise it or not. Its just delaying the inevitable.
December 7, 2017 at 4:46 am
I've come across only a few real situations where there is a genuine advantage in using a non-relational datastore compared to a relational data store. The usual "advantages" touted tend to stem around the fact that the front end developers don't understand databases, let alone database design and management, and definitely not optimisation and therefore just want a "magic" data store that will somehow do everything on their behalf. Usually by throwing more memory and processing bandwidth at a trivial but non-sensical structure and hoping for the best. All too often if it's not a non-relational data store, it's a relational datastore where the framework creates the database design on behalf of the developer who will inevitably accept all the defaults and care nothing about design, management nor optimisation in any context other than the current, immediate one - which is usually a live user interface and nothing else. As a result, barely fit for purpose database structures get spewn out and it's no wonder that the developers then start dreaming that a non-relational datastore might perform better.
December 7, 2017 at 6:44 am
For almost all my business, side and hobby projects a RDMS has sufficed. There's only a few outliers that involve insanely large amounts of real time data that something else is required.
December 7, 2017 at 7:49 am
NoSQL databases today are like what Object Oriented databases were - a niche solution to very specific situations. By and large RDBMS is the way to go for persistent data storage and retrieval.
December 7, 2017 at 10:42 am
chrisn-585491 - Thursday, December 7, 2017 6:44 AMFor almost all my business, side and hobby projects a RDMS has sufficed. There's only a few outliers that involve insanely large amounts of real time data that something else is required.
This is the one place I think specialized systems work well. Streaming databases are built to handle large volumes in real time and process a portion.
December 7, 2017 at 11:15 am
You guys are talking about data design, but there is another good reason for an RDMS--it is a big abstraction layer so that you don't have to worry about things like memory paging and block IO. If you pick a NoSQL database, you better make sure they have given more than a little thought to such issues.
Another issue is governance. How much private data do we have, who has access to it and who has seen it? Act as if you don't care about such issues and you might have an army of auditors in your knickers.
December 7, 2017 at 11:24 am
I really like this article. However, coming at this more from a developer's point of view, I can understand the attraction of the new and shiny thing. It's fun working with the new and shiny. But, I temper my enthusiasm by remembering what a friend of mine who is a manager at another company said, "Don't tell me that something is cool. Tell me why it will improve what we do."
One more thing. Please be patient on us developers because sometimes the desire to do something with some shiny, new, cool tool is because we've seen the job market trend and know that companies are abandoning what we've worked with and moving on to some new tool. Some choices carry along with them impact upon one's career. For myself, I don't chase after all the latest tech fads, but I do look at them and as best I can decide upon what's going to last and what I can focus upon. Then I'll go after that.
Kindest Regards, Rod Connect with me on LinkedIn.
December 7, 2017 at 9:01 pm
I'm actually not digging this article too much, but I love the debate.
I really dislike the idea that selecting a new piece of technology, whatever it is, is often lobbed into a bucket of, "just picking the new shiny!" I also really dislike the argument that developers code is not as important as the database. Like all of a sudden, it doesn't really matter what framework you use, but it really matters whether or not you choose NoSQL versus RDBMS? I mean seriously, what sense does that even make? They both matter -- developer and DBA together.
To talk realistically about data stores, I'm not a developer specifically yet I see great value in data stores. The value I see them having is sort of landing pads that sit before the RDBMS. It's been extremely beneficial to have something that allows you to lob data into it extremely easy and start analyzing it as soon as it hits the disk. No need to worry about how it fits into the complex data model or complex ETL pipeline you pride yourself on. Just upload, query, and enjoy.
If you can't tell, I am a fan of them. Data Warehouse with Polybase and Azure Data Lake Store seems like a great combination thus far.
That being said, there are some pretty wild assumptions being made here about certain professions and the reasons they choose certain technologies. Like all of a sudden the RDBMS is not as useful anymore or that a proper well maintained data model is more important than anything else the team is doing. This is absolutely not true on either end. Data stores are not going to replace a proper RDBMS anytime soon just as a well maintained RDBMS is not the answer to all solutions the need data management. As the infamous quote implies, not everything is a nail where your whatever is the hammer. A data store is just another tool in the toolbox that from my experience deserves to be there if used right.
Sorry if that sounds a bit negative. I know you mean well Steve in terms of the discussion.
December 7, 2017 at 10:00 pm
The problem is not only that developers don't understand SQL and/or relational databases.
The simply don't understand the data requirements of the applications they are developing.
There are obviously many reasons for this, but one of the biggest is time constraint where applications are pushed into the market as fast as possible.
Little time is spend to understand and create a proper data model, so NoSQL seems like an easy alternative.
December 8, 2017 at 12:12 am
Point in time restores and even diff backups. These should not be cause for nostalgia
December 8, 2017 at 2:26 am
Curiously I am just now working on a system that exactly fits one of the edge cases mentioned where NoSQL isn't completely daft - the survey monkey case. Most of the data lives in a kay/value table, but I am using MSSQL anyhow because MSSQL FTI is hard to beat, and some of the data is relational. The lists for selectors (pick list UI) can be embedded in the document but they can also be promoted to a row of their own in a table of lists. That's still rather NoSQL, being another key/value store with another JSON value, but there are other column identifying who owns what. Picking out the list of lists for a particular user is a not a task I'd like to undertake without a relational query engine. Not once you have documents that are created by a user but owned by a custodian that delegates permissions via nested roles (access control lists).
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply