Why Does Everyone Still Focus on Relational Databases?



  • 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?



  • 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.



  • @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.


  • Banned

    This post is deleted!

  • Banned

    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?





  • @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.

    0_1471380483805_Screenshot from 2016-08-16 16-47-43.png

    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.