Why Does Everyone Still Focus on Relational Databases?

scottalanmiller

I still see this like every day in every community.... everyone is fixated on relational databases and never seem to consider, use or even look into NoSQL (non-relational databases.) Not only this, but it appears to have become a thing to confuse the term SQL (a language designed to query a data source) with "relational database", which is a specific means of storing data in a mathematically defined manner. SQL has never meant that and can be used to query all kinds of non-relational data, so is in no way a synonym for a relational database, not even by association.

But confusion around names aside, non-relational databases predate relational ones and have been in continuous use since computers were first used and now, for the past decade, tons of really amazing new databases technologies have emerged in the NoSQL space with scalability, durability and performance, not to mention ease of use, advancements that put the relational world to shame (although they do some awesome stuff, too.) Relational databases have lots of viable use cases, they are totally critical for payment processing and accounting systems, for example. But by and large, for most use cases, NoSQL makes way more sense. It should be something like 80% NoSQL and 20% Relational for new deployments, right? More or less.

Partly this is because relational is just one kind of database and NoSQL is a catch-all term for "everything else" which includes an awful lot of different things.

But in posts and discussions, I still see relational databases used for effectively everything. I understand old products that were built before good, modern NoSQL options were available. That makes total sense. But for new projects and deployments, it seems like no one is even considering the most obvious options. What drives so many people to leap to such an unlikely choice time after time? What's keeping everyone from moving to NoSQL options (Redis, MongoDB, Cassandra, CouchDB, SimpleDB, on and on) when they are often so applicable and offer potentially so much more?

Dashrender

I'm surprised you are asking this question. To me it seems pretty obvious. People do what they know. If those other things are newer, then they aren't as well known. People being the lazy creatures they are, they stick with what they know until forced to something different.

mlnews

@Dashrender said in Why Does Everyone Still Focus on Relational Databases?:

I'm surprised you are asking this question. To me it seems pretty obvious. People do what they know.

I guess that I should have added...

They almost never seem to know relational databases either.
They do tons more work.

JaredBusch

Other databases are just so damned unrelatable though.

scottalanmiller

@JaredBusch said in Why Does Everyone Still Focus on Relational Databases?:

Other databases are just so damned unrelatable though.

IT professional treasure the value of relationships?

JaredBusch

@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:

@JaredBusch said in Why Does Everyone Still Focus on Relational Databases?:

Other databases are just so damned unrelatable though.

IT professional treasure the value of relationships?

I my databases

momurda

Can you give an example of when a nosql db would be better? I am trying to think of 1 instance where it would be better and can think of 0 outside of Facebook, Amazon, and other companies with billions of transactions/day. They are extreme cases of load/transactions. Might as well be a different world than what 99.999% of other shops are doing.

scottalanmiller

@momurda said in Why Does Everyone Still Focus on Relational Databases?:

Can you give an example of when a nosql db would be better? I am trying to think of 1 instance where it would be better and can think of 0 outside of Facebook, Amazon, and other companies with billions of transactions/day. They are extreme cases of load/transactions. Might as well be a different world than what 99.999% of other shops are doing.

Sure....

Great example would be an RMM. Like Spiceworks. Using a relational database causes a ton of unnecessary overhead that has no purpose in data like that.

Another is content management systems for your websites. Perfect examples of where NoSQL would be better.

We are using a NoSQL system right here, right now. It's what gives us so much speed and flexibility.

Financial tick counters (the biggest financial database type) are always NoSQL, no relational system can keep up.

Pretty much any bespoke software project for an internal company that you can imagine, almost all should be NoSQL.

Nearly any case where an embedded database is considered, relationships are overkill. Or any case where MySQL was traditionally used because it lacked the standard benefits of relationships (integrity.)

A helpdesk is another perfect example.

aaron-closed account

This post is deleted!

aaron-closed account

This post is deleted!

dafyre

The problem I have is wrapping my head around things like this because I see how they are related...

How does one use NoSQL in such a way as to not have circular logic? I don't want to totally take over the topic with an example... but if that's what it takes...

scottalanmiller

Another perfect example that we are talking about.... logging! ELK and Graylog both use ElasticSearch with is NoSQL. Splunk uses its own NoSQL database for this. Pretty much all logging goes to NoSQL.

scottalanmiller

@dafyre said in Why Does Everyone Still Focus on Relational Databases?:

How does one use NoSQL in such a way as to not have circular logic? I don't want to totally take over the topic with an example... but if that's what it takes...

Circular logic?

IRJ

Here is a good article comparing the two.

https://azure.microsoft.com/en-us/documentation/articles/documentdb-nosql-vs-sql/

dafyre

@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:

@dafyre said in Why Does Everyone Still Focus on Relational Databases?:

How does one use NoSQL in such a way as to not have circular logic? I don't want to totally take over the topic with an example... but if that's what it takes...

Circular logic?

It'll take me a couple of hops to get there... so let's do it in small chunks. We'll take a helpdesk ticket with the following fields, for example... (Done in RDMS layout)

Tickets Table:

ticketID:
CreatedBy:  <int> userID,
AssignedTo: <int> userID,
TicketSubject: <string>
TicketDetails:  <string>

User Table:

userID:<int>
firstName:<string>
lastName:<string>

In MySQL, we'd do table joins to generate the name of the user who created the ticket, and the person who is assigned to the ticket.

How would you go about laying that out in NoSQL?

dafyre

Found a nice little comparison of terminology from MongoDB here:

https://www.mongodb.com/compare/mongodb-mysql

Just look under the Terminology & Concepts

scottalanmiller

@dafyre said in Why Does Everyone Still Focus on Relational Databases?:

How would you go about laying that out in NoSQL?

Remember that NoSQL is not a "thing". NoSQL is only NOT a thing. So every type of database handles things differently.

dafyre

@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:

@dafyre said in Why Does Everyone Still Focus on Relational Databases?:

How would you go about laying that out in NoSQL?

Remember that NoSQL is not a "thing". NoSQL is only NOT a thing. So every type of database handles things differently.

Yeah, I get that. That's why I'm taking it slow. How would you do that in Mongo?

scottalanmiller

So MongoDB is a document database and it's the kind that would be used most commonly for a helpdesk ticketing system. So you would store stuff more like a real world ticket, it's actually the more obvious of the two approaches.

It would have fields, not unlike XML (but it uses JSON.) And those fields are like in Word or OneNote, not like a normal database. They don't have to match in document to document.

So it might be like ...

Name:
Ticket Number:
Description:
Asset Tag:

Now the data in Name might be an ID, not a real name. But it is the application that decides on that, not the database.

dafyre

@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:

So MongoDB is a document database and it's the kind that would be used most commonly for a helpdesk ticketing system. So you would store stuff more like a real world ticket, it's actually the more obvious of the two approaches.

It would have fields, not unlike XML (but it uses JSON.) And those fields are like in Word or OneNote, not like a normal database. They don't have to match in document to document.

So it might be like ...

Name:
Ticket Number:
Description:
Asset Tag:

Now the data in Name might be an ID, not a real name. But it is the application that decides on that, not the database.

You forgot the Assigned Tech(s).