Why Does Everyone Still Focus on Relational Databases?
-
@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.
-
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
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?
Yes, you would expect those to be a part of the single document.
-
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@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?
I think the point @dafyre is making here is it is so much easier from a devoloper standpoint to work with knowns instead of unknowns.
-
How are data in NoSQL db stored, referenced, retrieved?
In helpdesk relational db, i have tickets, tickets are created by users, users have relationship with other tables by keys. These relationships allow me to get meaningful data if it want by using joins and queries.
How would all this be stored in NoSQL? Does each ticket created become its own 'document' or entity blob, with the metadata such as user, assigned tech, date, etc available for query without having to use a join? -
@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
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?
Yes, you would expect those to be a part of the single document.
Right.... and you would also expect Technicians to be part of that document... But if you record the Technician's ticket history as part of the Technician's Document... You wind up with ...
Created By: Ticket Number Ticket Subject Ticket Details Ticket Comments <ticket comment 1>....<ticket comment N> Assigned Techs: <technician 1> <technician 1 - history ticket item 10> <technician 1 - history this ticket> <technician N> -
@IRJ I'm kinda going at it from that angle too, but I think I'm about to the point I can ask my question.
