Books online state: “There is nothing a graph database can achieve, which cannot be achieved using a relational database.” Why then are we putting graph technology in SQL Server? To help me answer this question, I invite my friend AZ to chat about the Graph feature in SQL Server 2017 and introduce how graph differs from a relational model. If you have every tried to implement complicated hierarchies in SQL Server, you know what a pain this can be. I, for one, am hopeful this new feature will allow us to tackle the various relationships even though it may be lacking certain features compared with other graph databases.
Are you using graph technology in SQL Server or even another platform? I would be very interested to getting your thoughts on what you like and what you still find painful.
Episode Quotes
“We have lots of hidden columns that are not accessible, that SQL Server uses to maintain those behind the scenes.”
“In SQL Server, the more number of tables you join, it’s going to slow down exponentially. In a graph database, technically it should be linear, so you should see no slowing down if the number of tables increases. That’s one of the goals of a graph database.”
“There’s no way for you to do an installation to not install this component. It comes with the engine.”
“You don’t have to bring everything into the graph tables. All you need to do is bring in the keys for querying and things like that. You could use the Graph DB portion and refer back to the SQL Server tables for the data part of it.”
Listen to Learn
00:41 Intro
01:08 Compañero Shout-Outs
01:51 Tips & Tricks
03:46 Conference
04:25 Intro to the guest and topic
06:22 The purpose of Graph Database
07:36 How Graph is different from relational
10:20 Where might tooling be going in the next iteration?
12:25 Interacting with these tables in SSMS
15:22 The challenge of the visualization
17:29 Who will want to use Graph Database?
18:58 Other ways to see relationships?
20:59 Thoughts for developers
22:30 JSON support?
23:30 Possible future improvements and comparison to other graph databases
25:47 SQL Family Questions
30:21 Closing Thoughts
About Azhagappan (Az) Arunachalam
Azhagappan (Az) Arunachalam has been working with SQL Server since v4.21/SQLNT. He started his career with troubleshooting at chip level, worked as a network engineer managing Novell NetWare networks, graduated into managing Windows NT, moved onto development, administered databases, and is currently working as an application database architect. He’s excited about all the cloud offerings that Microsoft and others have made possible, and in sharing his findings with aspiring data enthusiasts. He is a member of the Richmond Virginia PASS SQL Server Usergroup, and helps organize the SQLSaturday. He can be reached on twitter at @sqlaz.
Az’s blog: sqlaz.com
Credits
“Happy Rock” for Tips & Tricks by https://www.bensound.com
*Untranscribed Introduction*
Carlos: Compañeros! Welcome back to the SQL Trail. This is Episode 129 of the SQL Data Partners podcast. Our guest today is Az. He is here locally in Richmond. He was our guest in Episode 61, I believe, talking about USQL. He’s back and today we’re going to be talking about Graph Databases, giving an introduction or an overview to them and how we might be able to take advantage of that in SQL Server 2017.
Before we get into that, we do have a couple of Compañero Shout-outs. The first, to Grant Fritchey. We are having our SQL Saturday this weekend and we were lucky enough to have Grant come down to our user group and talk with us last night. Then he, Andy, Kelly and I went out afterwards and chatted for a good bit. It’s always nice to catch up with him, see what he’s doing. Shout-out to David Stokes who came up for the pre-con from Hampton. Of course, David is a regular compañero listener, so it’s always good to spend time with David. Want to give shout-outs to Bryan Hundley for connecting with us on Twitter. David Zeng and Jason Lamb for connecting with us on LinkedIn. Hope you all are doing well, and it’s nice to catch up with you.
Today we do have a Tip and Trick that I want to pass along, from listener Douglas Kemp. Douglas has actually been able to play with some new features that I admit I have been wanting to get my hands. It’s been on my To Do list, but I haven’t been able to do. He actually has used the rollover, the rolling upgrade feature. So now, with Windows Clustering, you can go from a 2012 to a 2016 if you’re using Windows Server 2016. Whereas before, you had to have the same OS version, now from an upgrade perspective, you can connect with a different Windows OS and upgrade that SQL Server. That’s what he had done. He installed Windows 2016 with SQL Server 2016 and was looking to do the rolling upgrade. He moved everything over, failed it over, that worked fine. Then he went back, refreshed the, what is now the secondary server, got that all ready, popped it back in, but what he said that it showed that it was synchronizing and recovering, which he thought was strange. Normally, we’re used to seeing synchronizing, because we have the two nodes, and obviously the data’s moving back and forth between the two of them, but he was confused by the restoring. It wasn’t until he failed back over to that secondary node that the new version settings were applied and that ultimately, the entire cluster was now a 2016. So, it seems like there’s a check in there that says, “hey, I need to make sure that all my nodes are at 2016 before I will upgrade”. Once he did that, the restoring status disappeared and his cluster was happy and available. Thanks, Douglas, for that tip. For those of you who are thinking about doing those upgrades, that might come in handy for you as to why you’re seeing that, in the future. That, compañeros, is today’s Tip and Trick.
We are also still working out our speakers. I can confirm the dates for SQL Trail 2018. It will be October 10th through the 12th. It will be here in Richmond. As I mentioned, we are still working out some of the speakers. We have a great venue downtown, which I think is going to provide lots of flexibility for us, which is one of the things that we’re looking for. We are probably going to open registration in late April, so we’re still a little way off from doing that, or the first of May. We’re still putting together the website, transitioning to the new SQLTrail.com, but that’s exciting. We’re excited to continue to put this together, and we think we’re going to have another great conference.
As we mentioned, today’s episode is on SQL Graph, so one of the interesting things about SQL Graph is a new feature, SQL Server 2107 only. Today our conversation is going to revolve around what is it, how we might start using it, and Az has some interesting thoughts on that. In addition, to what the future might hold, because obviously this is a version one feature. Our show notes for today’s episode, Az has a couple of images. I’m not sure he’s doing videos, but he has a couple of things on his blog and we will post that up on the show notes for today’s episode is sqldatapartners.com/graph or sqldatapartners.com/129. With that, let’s go ahead and jump into the conversation with Az.
Carlos: Az, it’s great to have you back on the program! Welcome!
Az: Thank you, good to be here, Carlos.
Carlos: Yeah, so just going back over the calendar, you were with us in episode 60, talking about USQL. So, today, we’re going to be switching gears a little bit and talking about the Graph Database, but thanks for coming back on and chatting with us.
Az: Glad to be here, thank you.
Carlos: In preparation for this episode, I go to books online and it says, now this comes from the Microsoft Documentation, mind you, so that’s where I’m reading this. “There is nothing a graph database can achieve, which cannot be achieved using a relational database.”
Az: That’s right. At least with this iteration, yes.
Carlos: So then tell me, why is graph technology been implemented into the database?
Az: There are lots of other graph databases that have lots of other features, but right now we are in the first version of this in SQL Server. It kind of makes some of those queries easier, but there’s nothing that you can do using Graph Database that you cannot already do using the relational. But when you have to write some queries, it’s much easier to, actually, with the way the syntax has been restructured, so it’s easier to follow through.
Carlos: So yeah, that is the point, the ability or the ease of which you can pull relationships or demonstrate relationships.
Az: That’s right.
Carlos: If you think about social networking, fraud detection, IT network analysis, transportation network, social product or content recommendations. So, these strongly defined relationships over multiple points, you might call them many-to-many relationships.
Az: Yeah, they really shine there, yes.
Carlos: That’s right, so that is kind of the purpose or the goal of the Graph Database.
Az: That’s right.
Carlos: And they’ve introduced that, now. Again, we can do recursion in SQL Server and it is possible, but it reminds me, I remember sitting in Louis Davidson’s session talking a little bit about hierarchy. He had a 500-node example and then he’s like “oh, okay, and then we’re going to change number 247.” And the amount of work and effort that was involved to make all those changes, I thought, “okay, so this is a feature I’ll never implement”. Because, you know, it was so cumbersome. It was so difficult to put together. So, I think now that we have Graph Database, in theory, it will be easier to put that together. Now, I think this is where we get into, it is a different model. It’s a different database model. I think that’s the right word for it. We’re used to the relational model. We have two tables, and they’re related by a foreign key. Now that foreign key is an object in the database. We don’t see it, we can’t look at the data and tell that there’s a relationship there.
Az: Yeah, the relationships are made in a separate table. They are called the edge table that show the relationship between the nodes. So, we have a separate table. All it does it talk to the relationships.
Carlos: Yes, so that’s on the graph side. Now we have these two types, nodes and edges. Nodes are the objects, if you will, that we’re talking about. And because I saw your presentation, we’ll extend the example that you had there. This is “people that I know” and “authors of books” or even “books”, that example, and you can have multiple relationships regarding that. The node is the person, and then the edge, as you just described it, is that relationship. What I think is interesting is that, like we talked about, you can’t look at the data in a relational table, just looking at the data itself, and know that there is a relationship. But as you mentioned, I go to the edge, and I’m actually saying, “hey, this Node ID of 1 corresponds to or has a relationship with Node ID of 10 or whatever” and I can see that. I think it makes it easier to understand or to form ideas about what’s going on with the data.
Az: That’s right. At least with this iteration, the very first iteration of the SQL Graph in SQL Server doesn’t have a UI, meaning like a graphical UI, so you can’t individually look at data and then direct any relationship. You have other companies that’s actually like Neo4j and other databases, just looking at it, you can try to direct some relationship between different entities in the relationships. But right now, we can use PowerBI. Nothing is there that’s available out of the box, actually, with SSMS. Probably that may be coming in subsequent versions, but not as of now.
Carlos: Yeah, and that is one of the challenges, I think, or the hops that I needed to get as I was looking at this after I saw your presentation, and you tend to think of the graph as the image. There’s a circle, and then there’s a line to another circle. And then you look at it in SQL Server and you’re like, “wait a second, that doesn’t look like what I was expecting”. Yeah, I think it’ll be interesting to see how that plays out, but yeah, you have to look at the data and that’s really all you have in this first version of SQL Server.
Az: That’s right.
Carlos: Obviously we don’t know, but if you were to look down at the next iteration, where do you think that tooling is going to go?
Az: I would expect at least some kind of dynamic relationships. With Neo4j, if you want to have a new relationship between a node, all you have to do is just create it on the fly, because it’s a pure node SQL database. But here, they kind of implemented this extension of the relational database, so you have to create a new edge table to have any kind of new relationship. You cannot just on-the-fly create a relationship. You have to create an edge table, and then you have to create, either it’s going to be one-way or two-way. You have to make some entries in the edge table between two nodes. It’s not as dynamic as we want it to be. I would expect in subsequent versions, we might get those features in.
Carlos: Interesting. Yeah, that’s an important piece to remember is that you are creating, it’s basically the same old table that we’ve had, and I can’t remember, the nodes I think it’s all the same, but the edge is where we get the JSON data.
Az: No, JSON is how they represent the IDs so that we can use it in our application.
Carlos: Oh, gotcha.
Az: Internally, they’re stored as inter begins or something like that, but they expose it as (?) of thousand and you get the JSON string. That JSON has one type of node or whatever object it is, if it’s a node or an edge. And then you have the schema, the table and then the IDs.
Carlos: Okay. So, yes, we’re not going to see the foreign key relationship, as we mentioned. The data is just going to tell us how the matches are there. But there are some different ways in which we’re going to be able to see or interact with this inside of SQL Server. So in sys.tables, there’s a couple of changes there.
Az: That’s right. So in sys.tables, we have two additional–
Carlos: Columns?
Az: We have lots of hidden columns that are not accessible, that SQL Server uses to maintain those behind the scenes.
Carlos: Oh, gotcha, we get to see two, but there’s many more behind the scenes.
Az: Yeah, a lot more behind the scenes.
Carlos: And then in SSMS, how are we interacting with these tables?
Az: Just like regular queries, you can just make some calls. You just do a select (?) from whatever the table name is, a node or an edge. But if you want to look at the relationship (?) a match predicate, so you can use those predicate instead of usually what we see is, like in relational database, the more number of tables you do joins, the slower the query becomes. They’re trying to improvise on that, actually, so that instead of in a typical graph database, the more number of tables you join, it should be linear instead of exponential. In SQL Server, the more number of tables you join, it’s going to slow down exponentially. That is the reason in a database, they kind of denormalize, whereas, in a graph database, technically it should be linear, rather than exponential, so you should see no slowing down if the number of tables increases. So that’s kind of one of the goals of a graph database.
Carlos: Interesting. Regardless of the number of nodes?
Az: That’s right. The number of joins.
Carlos: Oh, the number of joins, okay. You brought up the match predicate. That is how we define those relationships, so instead of INNER JOIN TABLE 1 ON and show the relationship, we’re going to use that matches predicate.
Az: That’s right. They got rid of all the join keyword at all, so early Microsoft was seeing, you select certain columns from table one INNER JOIN TABLE 2 ON whatever the conditions are. That’s what they were recommending. Now we’re kind of going one step back, we say SELECT COLUMNS FROM TABLE 1, TABLE TWO that match whatever the conditions you have the predicates in there. So, it’s kind of like we are going back to TABLE 1, TABLE 2, TABLE 3 kind of thing. They were kind of discouraging us earlier. But we are back to that, so hopefully we’ll go back to the earlier one, actually. They want to avoid the JOIN keyword there, so I think that’s kind of the premise where they’re headed in this direction.
Carlos: You think that’s just more to avoid confusion to help identify, “hey this is a graph table, this is a relational table”? Or do you think there’s some other reason behind that?
Az: I think they just want to get it off the JOINs because the match is going to take the equivalent JOIN statements. They want to get it off the JOIN, but then all the while, they were kind of corralling us to go down that road. Now they’re asking us to step back, so hopefully they’ll come back with something that’s consistent that we can use for graph as well as for relational.
Carlos: One additional item I did see in SSMS is that those graph tables are now stored in a folder, very similar to the system tables that we might, in the newer versions of SSMS.
Az: Yeah, that’s just the GUI in SSMS, but if you look in SQL Operations Studio, you won’t see the separate folder, actually.
Carlos: Oh, okay.
Az: Yeah, so just SSMS probably to that option. I think it’s all based on the type of table it is, based on that it kind of groups them into different folders. Just kind of from UI, I would say. Just an organizational thing.
Carlos: Now, going back to this challenge of the visualization. We’ve gotten used to JOINs and then of course with graph, they’re showing us the circles and the lines together. How have you managed to begin the process of understanding those relationships, or thinking about them in a different way, beyond the traditional relational model?
Az: I would start with an INNER JOIN thing, INNER JOIN or LEFT JOIN or something like that, and then try to model that and try to come up with what is equivalent using the match predicate, and then try to go from there. It’s kind of equivalent to that, but then it’s much simplified. If you have like 10 JOINs and the conditions are probably 10 conditions or something like that, you can try it in a couple of matches. It kind of simplifies order that comes after the WHERE clause, instead of having multiple things like WHERE this condition is (?) this, this table 1 dot column is equivalent to table 2 dot whatever column, things like that. You create an alias in the front clause and then you refer to that in the match predicate. And they use something called chart or ask a (?) where everything is a percent using just alphabets of the alias names within parenthesis and the arrows.
Carlos: Right. Yes, that syntax is a little different as well.
Az: Yeah, a little bit different, actually. I’ve used Neo4j. Neo4j, the entities or the nodes are represented within circular parenthesis and then you represent the arrows going towards whether it’s a LEFT BOND or RIGHT BOND and then you have the relationship and then you have the other node. In SQL Server, it’s a little bit different. You don’t encapsulate nodes within any parenthesis or anything like that. Nodes have just the alias and then you have the directional thing and then the edges, they have parenthesis. So, nodes, dash within parenthesis whatever the edges are you are referring to, and then another dash and then arrows depending on whether you go from left to right or right to left, and then another node.
Carlos: Right, so that’s the nomenclature. Those arrows indicate the direction of the relationship, there. That will take some getting used to and I think we’ll all have to have some test queries before we get that there. So, other thoughts on getting started? We talked about hierarchies, and I think in the traditional business sense, the employee/manager is probably the typical choice. Under what circumstances, or what other examples maybe would you find people wanting to pick up the Graph Database?
Az: One of the limitations with the hierarchy is you can have a single (?) can only look up to one pattern. You can’t have multiple patterns. But with the graph database, you can have multiple patterns for the (?). That’s one of the things, and again, we can use it for (?) accommodation systems and things like that. This person who bought this book also purchased other book, whatever you see, from Amazon or LinkedIn. Okay, this person knows it, probably there’s a chance that you may also know him or probably you might want to extend an invitation to him. Things like that. Those are some of the use cases for the Graph Database. Almost all of the big companies have some implementation of graph database. This is Microsoft SQL Server’s actually. They already have in the Cosmos DB, but for people who are already used to using SQL Server, they don’t want those people to go on and use a different database. This is just an effort for them to give those features within the SQL Server. They made an extension of the engine, so it comes with the engine. There’s no way for you to do an installation to not install this component. It comes with the engine. So, whether you (?) or something, once you install it, it comes with the engine.
Carlos: Yeah, that’s an important point. I don’t have to do anything differently to get this feature. It is baked in.
Az: That’s right. They call it SQL Graph Extension.
Carlos: When you talk about using Graph and tools that can consume it, we already talked about PowerBI, does that mean that PowerBI is the only “current tool” that has the extensions to be able to read those relationships? I mean, I feel like, it’s JSON data, I could display that and then even have Reporting Services read that.
Az: Yes, it’s a JSON data. You can develop your own custom control and again display it however you want it. Microsoft with the PowerBI they already have a graph-type called false graph. That’s developed by Microsoft, so that’s available in the gallery. So, you just pull that into PowerBI and that kind of out of the box (?) to that experience where you can see the edges and nodes and those kind of stuff. But it’s just JSON data, so if you have some data control, UI control that can display that, yeah, you’re more than welcome to use that. But there is nothing out of the box within SSMS that you can look at it.
Carlos: Gotcha. Well, other than selecting from it and then you’d have to figure out how you’re going to display it, because the query will return results.
Az: Yes. The only thing is you have to go outside of that environment to visualize it. That is the shortcoming with the current version. And if you’re using SQL Operations Studio, you have the option to create your own widgets, so probably if you have some graphing capability, come up with your own way of putting together things like you can create your own visual displayed as part of the SQL Operations Studio.
Carlos: Yeah, so that will be something you’ll have to show me afterwards, because I did try actually playing with those widgets, and I could not figure out how to create my own.
Az: Some of those things are available in the gallery but you have the option to extend it yourself, so yeah, probably I can show you afterwards.
Carlos: I guess was not even familiar with the Operations Studio gallery. There’s a gallery for the Operations Studio, huh?
Az: Yeah, so with (?) something that’s available right out of the box you can’t use it, but it an option to extend it, yeah. So, if you know some (?) or some programming, you can create your own widget and then you should be able to incorporate that.
Carlos: Obviously we talked about displaying it. If I’m going to start developing with Graph Database, I have to have a way to consume that data and then display it. Other thoughts that developers might need to know when they start working with it?
Az: One thing is you don’t have to know, all you need is the graphing engine could be used only for the JOINs. Sometimes if you have existing data in the regular SQL tables, you can use that table also in the query. The only thing is they cannot be used in the match predicate. The regular SQL Server tables. But the rest of the data can still be there. As you may have lots of image data, or the other kind of data, like (?) and things like that, you don’t have to bring everything into the graph tables. Those things can remain there. All you need to do is just bring in the keys for querying and things like that. You could use the Graph DB portion of it and still refer back to the SQL Server tables for the data part of it.
Carlos: Okay, yeah, so that’s an important point. You don’t necessarily have to push everything into the Graph Database.
Az: That’s right, you can mix and match.
Carlos: Okay, yeah, that will be fun. So, from the execution plan, if I look at that, am I doing another remote procedure call as well, or do I actually get to get some data on what it’s doing there with the nodes?
Az: I think with the plan you should be able to select what it’s doing behind the scenes. They all translate to the regular JOINs behind the scenes. The engine does that for us. So, you should be able to look at the plan and see how the compiler does those things. Yeah, you should be able to see that.
Carlos: Okay. So, the Graph Database takes advantage of the JSON feature, which they introduced in 2017. Do you think that there are going to be other features that they introduce that are going to take advantage of the graph functionalities?
Az: I wouldn’t say they take advantage of the JSON functionality. They’re exposing the keys in JSON format.
Carlos: Okay, but it would have to have JSON support, don’t you think, in order for them to show that in JSON format, or no?
Az: No, the way SQL Server implemented it is they don’t have a JSON data type per se. All that they have is (?).
Carlos: That’s true.
Az: So, they’re just displaying it in that format so the application can consume it, because we have lots of other libraries that can easily, given a JSON string, it can access that through different hierarchies. We already have the object model on the development site, so they expose it as such, so it’s easy for us to consume it. I don’t think they’re maintaining it in JSON.
Carlos: Yeah, okay, that makes sense. Well, awesome, thanks for giving us that overview, there. Other final thoughts about Graph Database?
Az: Yeah, some of the things like there are lots of internal features that are not exposed. They mention all the (?) fields and those things are kind of like they are of computed columns but when you query the sys.computed columns, you won’t find an entry there. So, certain things they are very internal. You don’t have access to some of those things. You can query some of those hidden columns. Hopefully in the future versions they’ll give us access. When you want to insert data into the edges table, you have to query both the nodes and get the ID and then insert it, so hopefully there’s a better way for us to enter data into the relation table. Lots of things that need to be improved before we can use it mainstream.
Carlos: Okay, yeah. Sometimes that makes me wonder, why do we need to see those columns, but I guess there could be some information that would be useful to us. So, we’ll have to see what future iterations hold for us, there.
Az: Yeah, that’s right. I’m looking at lots of other graph databases that are available on the market and the leading ones are the Neo4j and the CosmosDB. But Cosmos is a multi-model database, so you have other data types, like a key value (?) of column family and things like that, so out of which graph databases, one of them and that’s a no SQL data (?) and the one that’s available in the SQL Server is relational implementation of the Graph Database. So, it has its own limitations as to what you can do with that. And with the Neo4j, you can have– it’s got lots of other functions, so it’s a matured graph product. You can do polymorphic queries, transitive closure, a variable number of hobs. Like you don’t care about how many nodes or relations are there between two nodes, it can do multiple hobs and try to find some matches and things like that. So, those are not available with Graph Database, yet. Then, lots of building functions like a shortest path function and things, that’s available in Neo4j. You go from one place to another. Take, for example, Google Maps and things like that from one place to another. Either you want to go through the fastest route or the scenic route and things like that. You have different logic, so you want to find the shortest path. There are functions that does it, but here you have a (?) something like that and you have to implement it on your own. Those things are not available out of the box.
Carlos: Gotcha, so there are some helpers, if you will, that aren’t quite available just yet. So, it’ll be interesting to see what happens on the horizon, there. Awesome. So shall we go ahead and do SQL Family?
Az: Sure.
Carlos: Now, how did you first get started with SQL Server?
Az: Yeah, that was 20, 22 years back, actually. That was back in ’95. Yeah, that dates me. I was working on SQL version 4.2. That’s when I got started, and that’s back in Windows NT 3.51 days. I was doing my (?) and so I was pursuing that and I needed to take a couple of database certifications. So, I did SQL Server 4.2 administration and implementation. That’s how I got started, actually. I didn’t want to be a database administrator or anything like that. I came from a novel background. I was moving into the Microsoft Windows NT land, I was doing my Microsoft Systems Engineer certification at that point and time. So, out of seven or eight certifications that you need to do, two of them are database leader. So that’s my first foray into databases. I did a program using DBS (?), but not on the full-fledged (?) thing.
Carlos: Now, in all that time working with SQL Server, there’s been many changes, obviously, and we’ve just talked about one of the newest ones of the 2017 (?) and Graph Database. But if there’s one thing that you could change in SQL Server, what would it be?
Az: One thing. There are lots of things that could be made better, but I like the way how things are heading. I’m playing a lot out on with the dockers implementing or just creating containers from SQL Server images on the Windows container (?) and the Linux container. But images, there’s not a parity between those two environments. The image that I see on the Linux side, it’s 1.8GB or something for SQL Server. But if it had to create on the Windows side for the express, it took 13.8GB. and for a derivation, it took 15GB, actually. So even in docker, it’s kind of like the download of the image takes a long time. I think maybe because too many features are available on the Windows side. Not everything is available on Linux side, yet.
Carlos: Yeah, pretty much just the engine. So, all of the other things like SSAS or other things just aren’t available. SSIS, all that stuff. Yeah, so it’ll be interesting to see what happens there.
Az: And they have (?) code that’s available ported to other platforms, so you could use some of them on the Linux (?). I like where things are headed, there are too many things that I’d like to see changed, but I don’t know if I can point to just one, actually. In graphing, there are lots of other places where things could be improved, like creation of relationships on the fly instead of creating a table and then establishing it. And then some better way of inputting the relationships, instead of querying the nodes and then getting the IDs and then inserting into the relationship table. So, those would be a couple of things that they could improve.
Carlos: Yeah, you want to look forward to. Okay, very cool. What’s the best piece of career advice you’ve received?
Az: I’ve received a lot of advice from a lot of people. If I had to remember one thing, I like the quote from Martin Luther King, actually. “It doesn’t matter what you are, be the best at it.” Like if a man is called to be a street sweeper or something, he might as well be the best sweeper or something like that. So, whatever you take, just be the best in that.
Carlos: There you go, I like that. In a world where, social media, we’re always comparing ourselves to other people, what an interesting change it would be just to think about what it is we’re doing and be the very best at that. Az, our last question for you today. If you could have one superhero power, what would it be and why do you want it?
Az: I think I would go with the same thing that I did when I was asked a similar question in USQL. If there’s some way by which I can absorb information quickly, because I’ve got so many books and I haven’t read through them. So again, if there’s some way I can assimilate all this information, I would go with that. Probably like listening to speeches or I think that’s faster than reading books. I love reading, but then there’s only so much I can do, and then there’s, yeah, I can’t read faster. Some people have that photographic memory and they can scan through a book like that. I wish I had that ability. Probably just scan a book and then get all the contents absorbed. I would love that.
Carlos: There you go, yes, that would be a very interesting way to learn. Push the capacities of our brain to the edges there, I think. Very cool. Well, Az, thanks so much for being on the program today. We do appreciate it.
Az: Thanks for having me here.
Carlos: If you’ve had to do those hierarchies, and then had to do recursion to get that information out, I think that Graph is going to be a welcome, albeit a different, type of change. Yes, we are introducing a new database technology, if you will, although we’re still using tables, they just have different syntax, a bit, around that. But I think that this is going to allow us to interact with data in different ways, and I think it’s cool to see SQL Server change and evolve with that, too. And I think that as data professionals, that ability to interact with data and be able to interact with it easier, I’ll say, and then provide more value for our users, can only be good, and help open us up to additional or other opportunities that might come our way.
Compañeros, that’s going to do it for today’s episode. As always, we’re interested in hearing your thoughts. You can leave that on social media or on the show notes page. For today’s episode, it’s sqldatapartners.com/graph. Our music for Tips and Tricks is Happy Rock from bensound.com, used under Creative Commons. We hope you’ll connect with us on social media. I am available on LinkedIn. You can reach me @carloslchacon, and we’ll see you on the SQL Trail.
[…] SQL Data Partners Podcast Episode 129: Graph Databases (Carlos L. Chacon) […]