Why Does Everyone Still Focus on Relational Databases?
-
@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.
-
Other databases are just so damned unrelatable though.
-
@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?
-
@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 -
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.
-
@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.
-
This post is deleted! -
This post is deleted! -
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...
-
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.
-
@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?
-
Here is a good article comparing the two.
https://azure.microsoft.com/en-us/documentation/articles/documentdb-nosql-vs-sql/
-
@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?
-
Found a nice little comparison of terminology from MongoDB here:
https://www.mongodb.com/compare/mongodb-mysql
Just look under the Terminology & Concepts
-
@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.
-
@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?
-
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.
-
@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).
-
But yeah, that's generally what I was looking at...
So now, let's add in Ticket Comments.
We have 10 to 15 comments on a ticket. That would be come part of that tickets Document (record), right?
-
Here is a real world entry from ML with MongoDB.
It's a topic purge event. You can see the UID field is stamped, as is the action type, there is an IP/time stamp on it and then the contents of the document that have two entries.
