Why Does Everyone Still Focus on Relational Databases?
-
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.
-
@momurda said in Why Does Everyone Still Focus on Relational Databases?:
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?I think @momurda may have just asked my question for me, lol. Sometimes I need pictures, and sometimes I don't.
-
@momurda said in Why Does Everyone Still Focus on Relational Databases?:
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?Yes, that is generally how it works. Some things, like the username, might be an ID that is then retrieved from somewhere else, maybe not even the same database.
-
@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:
@momurda said in Why Does Everyone Still Focus on Relational Databases?:
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?Yes, that is generally how it works. Some things, like the username, might be an ID that is then retrieved from somewhere else, maybe not even the same database.
And this is where I get lost on the usefulness of the NoSQL Concept in general... How do I join up that data if I switch from using the user's name, to the User's ID?
One MySQL Query That may take three seconds becomes three MongoDB queries that the application then has to process, which could take 2 seconds each.
-
I'm trying to understand how the data is useful if there is no relation between the data.
I suppose if each entry is its own blog, OK fine, but why does that need to be in a DB? though I suppose a text file is technically a db, a non relational one.
-
@Dashrender said in Why Does Everyone Still Focus on Relational Databases?:
I suppose if each entry is its own blog, OK fine, but why does that need to be in a DB? though I suppose a text file is technically a db, a non relational one.
Where else COULD it be?
-
@Dashrender said in Why Does Everyone Still Focus on Relational Databases?:
I suppose if each entry is its own blog, OK fine, but why does that need to be in a DB?
Perhaps you are associating the term DB with relational database? Which would make that confusing.
