Your brochure request has been submitted to Airsweb successfully. Click the link below to download your Airsweb brochure directly to your device.Begin Download...
Hi everybody - Rob Leach Product Development Director for Airsweb. Here today to talk a few minutes about something a little bit more technology-based than usual. Here to
talk about SQL database and a graph database.
Don't get scared of everybody - not too much detail - but I think it's worthwhile discussing the differences and that one isn't leading to the others demise or vice-versa and that they can work together but the only way they can work together is if you've designed it from the very beginning.
So let's talk about SQL. It's been here for 40-plus years. What does it do? It's a relational database it's the workhorse of databases, it's where you store your data in lumps
of data. So for example a filing cabinet if you think of SQL as a filing cabinet, with drawers and files and you can go and retrieve a piece of data that's what SQL is great at. It's very good for structured table data with relationships, defined. If your data doesn't change a lot but you've got lots of data SQL is great for it.
Whereas graph, on the other hand, you can see by the diagram is very much what's called node based. You have nodes that relate to each other with behaviours these particular the key with graph databases that the actual behaviours - the relationships - are at the data level they're not at the table level - that's as technical as I'm going to get - but it allows you to have a very more dynamic structure.
It's very easy to add relationship it's very easy to add nodes but the beauty of as I say for SQL is is the workhorse it's saving incident data, it's saving audit data, it's retrieving that data for you to look at. Whereas this graph is talking about the relationships between the data. So in a good structured system when you save an incident, it would go possibly as a blob in your SQL database but it would also write the key elements of the data to your graph database and the behaviours and the relationships. So then you could
go in and say is this thing here related to this or I didn't know this thing in the middle seems to be related to all of these things I didn't know now so if I look at this thing it will tell me a bit more about all these other things this has got an impact or did I know this is always related to by this this is the bridge between the two.
For example, this might help you find out that a particular activity is at the center of all your incidents at a particular site or this causation actually precedes something that always happens further down the line. Through reading incidents, or in a graph, or some analysis - you wouldn't find that out. You need to traverse relationships to try and find what's called "fuzzy nodes" and to try and find out how these nodes related with it like I say causation is a key one. It will help you with the "did you knows?" of this world. Did you know somebody bought this on Amazon? Whereas this is - "Did you know this cause is actually so busy in these areas when this contractors on site when they're doing this activity?"
They're the relationships the graph exposes. That's the power of graph. It's not reading and writing lots and lots of data it's the relationships between the data - that's the key. So again this graph database technology doesn't mean the death of SQL and vice versa. They don't really do the same thing. If you do them properly they work in harmony if your structure is engineered from the ground up - you can't bolt one on to the other - not really good design - but if you start from scratch these two technologies work seamlessly but as I say for different applications.
Okay I'm Rob leech - hope you enjoyed that.
Our team would love to demonstrate the power of AVA for you in a one-on-one demo. If you would like to learn more then arrange a demo today!Arrange a Demo
You may also be interested in these AVA modules.