There is a growing need for Graph Databases in the market. This is a type of database, which is capable of storing, representing and manipulating graphs easily and efficiently. Common use cases for using Graph Databases are social networks and network topologies. In a Graph Database, there are nodes (e.g. people in a social network) and edges (e.g. connections between people). Each node and edge can have attributes. For example, a relationship between people in a social network can be “friends”, “colleagues” or “followers”. A Graph Database provides an API, which allows writing queries to easily traverse the graph and calculate things like transitive closure.
SQL Server 2017 provides Graph Database capabilities out of the box. You can now create two new special tables types: node tables and edge tables. You can also use the new MATCH T-SQL function to search a graph. With these new features, you can implement graphs for various use cases, just like you would do with other Graph Databases. Like many other features in SQL Server, these new features are part of the database engine. It’s not a separate engine with separate tools, like with other products. In SQL Server 2017, the same storage engine and query processor handle Graph queries. This means you can join between graph tables and other tables in a single query, and still get an optimized plan. This is a huge benefit of using Graph Database capabilities in SQL Server.
SQL Server implements node and edge tables as regular relational tables, and it translates the MATCH function to regular T-SQL constructs behind the scenes. In terms of interoperability, this is a huge advantage. Because it means that all the features in SQL Server that work with regular tables, also work with Graph tables. Think about indexes, backup & restore, import/export, etc. But the fact that Graph features are implemented using relational structures is also a drawback in terms of performance. It’s not an optimized engine designed specifically for Graph use cases. It means that it can perform as fast as a relational database – sometimes a bit faster, sometimes slower.
Want to learn more?
Comentarios