Why Does Everyone Still Focus on Relational Databases?
-
@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.
-
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@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.
Do yourself a favor, and forget about joins. They're a coding and performance nightmare waiting to happen, from the little I've seen. You can do the same things with simpler logic, faster, even within the database engines often times.
-
@travisdh1 said in Why Does Everyone Still Focus on Relational Databases?:
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@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.
Do yourself a favor, and forget about joins. They're a coding and performance nightmare waiting to happen, from the little I've seen. You can do the same things with simpler logic, faster, even within the database engines often times.
Yes, joins have importance to highly atomic transactions, but are generally pointless with normal, real world data. Tons of effort, tons of resources when something light and lightning fast would do the job better.
-
@travisdh1 said in Why Does Everyone Still Focus on Relational Databases?:
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@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.
Do yourself a favor, and forget about joins. They're a coding and performance nightmare waiting to happen, from the little I've seen. You can do the same things with simpler logic, faster, even within the database engines often times.
The data still has to be combined somewhere... Whether that be in a join, or in the application.... There's still effort that has to be put in to ensure you're pulling the correct data.
Doing the Joins pushes that out to the RDMS server... Doing it manually from MongoDB would push that back into the application code.
-
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@travisdh1 said in Why Does Everyone Still Focus on Relational Databases?:
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@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.
Do yourself a favor, and forget about joins. They're a coding and performance nightmare waiting to happen, from the little I've seen. You can do the same things with simpler logic, faster, even within the database engines often times.
The data still has to be combined somewhere... Whether that be in a join, or in the application.... There's still effort that has to be put in to ensure you're pulling the correct data.
Doing the Joins pushes that out to the RDMS server... Doing it manually from MongoDB would push that back into the application code.
Doing it in the application provides a lot of power, and a lot less locking.
-
@scottalanmiller said in Why Does Everyone Still Focus on Relational Databases?:
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@travisdh1 said in Why Does Everyone Still Focus on Relational Databases?:
@dafyre said in Why Does Everyone Still Focus on Relational Databases?:
@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.
Do yourself a favor, and forget about joins. They're a coding and performance nightmare waiting to happen, from the little I've seen. You can do the same things with simpler logic, faster, even within the database engines often times.
The data still has to be combined somewhere... Whether that be in a join, or in the application.... There's still effort that has to be put in to ensure you're pulling the correct data.
Doing the Joins pushes that out to the RDMS server... Doing it manually from MongoDB would push that back into the application code.
Doing it in the application provides a lot of power, and a lot less locking.
Moar flexibility too. I'm building (okay, tinkering with at this stage) a helpdesk in Meteor, just to see how it works in practice. In theory, it sounds good... We'll see how it works out in practice, lol.
-
It's my understanding that the main difference between relational and nosql is that relational is rigid and nosql is not.
If you design a relational DB, it's made up of tables, with certain data types, in a 2D structure of columns and rows, columns that are predefined for the table.
If you have a table with 50 columns, one row might have data in 25 columns and another row has data in 35 columns, but both rows have all 50 columns of data (even if blank, empty, null, etc)
In a nosql or "graph" type dataset, you don't necessarily worry about columns at all. One page might need 25 pieces of data and another page needs 35 pieces of data, no more, no less. More can be added later, or removed later. Not only that but each record may have completely different data.
I also think of nosql as somewhat 3D. You forgo the 2D relational style of rows/columns where multiple tables are linked by column IDs. Instead, ALL the data is stored in a 3D way in a single document, or graph. This is really the difference between something like CSV versus XML. Because XML can have sub-data and sub-sub-data all the way down.
In a relational database, if you have a "customer" table and want to allow that customer to have as many addresses assigned to them as they like, they you would be required to build a separate "addresses" table, then link records by user ID. If you wanted to delete addresses when a user is deleted, you'd need app logic or a foreign key relationship. But if you didn't delete the related data, you could have orphaned rows of data, lose those relationships, and the data starts to get ugly over time with bugs sneaking in.
In nosql, you just pull up the customer data and all their addresses are available in the record. They can have no addresses, or 30, doesn't matter.
If you have a ticketing system in nosql, then all data just gets stored in 3D like JSON or XML structures.
So the big question, what if you want to find all tickets by a certain user? Well that's what the nosql engine handles, you just search for the user and it finds all the records.
Should records be stored by ticket or by user? I would think it's by user, actually, and all the tickets and all the sub-information about those tickets get stored all the way down the line.
MongDB is essentially a JSON storage engine, that's exactly the type of data you store. It also means it's limited. If you have multiple nested levels, perhaps hundreds of bits of data, you can't just replace one small bit of data that changes, you have to write the entire document again.
MongoDB is perhaps the best choice for people who typically use relational but finding predefined columns a bit limiting.Redis excels for rapidly changing data but limited DB sizes. It works best when the entire DB can fit in available memory space. The data structure is more aligned with key:value type data.
Cassandra for when you just need to store a bazillion records, like analytics, hit counts and logging. Data can have its own expiration date set.
ElasticSearch is also JSON but can save parent and child documents and has more advanced searching when relating records together.
CouchDB is good for accumulated data that doesn't change much and you want to run the same queries all the time. Master-master replication is possible for multi-site deployments.
And yes I got all this info from a nifty chart here which is pretty handy: https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis?
Personally I haven't found a project that doesn't very easily fit in the relational DB mold. Most data, I think, is still relational, where some list of stuff belongs to or relates to some other list of stuff. As long as the idea of predefined data (columns) applies to the "list of stuff", relational is still good!
However, if the "list of stuff" is terribly random, such as "list of stuff in a person's closet" versus "list of stuff intalled in a PC" then it makes more sense to go nosql.
List of stuff in PC -> defined columns ["cpu", "RAM", "HDD", "Video Card"......]
List of stuff in a closet -> undefined columns [ {name: "shirt", color: "black"}, {name: "shoebox", contents: "pictures"}, {name: "vacuum"}, ........]It's all so magical!
