May 2, 2017 at 1:01 pm
Just wondered how much anyone has played with the new Graph Tables (Graph processing with SQL Server 2017).
I'm having a very quick play at the moment to see how it compares and it does makes me wonder why MS think they will compete with a normal Composite key table for many to many relationships. My knowledge of other RDMS's isn't great but are Graph tables something that already exists in Oracle (or other)?
The syntax is a little odd to my brain with the MATCH statement, but if it comes into common use I imagine I can get used to it.
So far, in my experiments, one thing I have noticed is that a clustered index isn't generated on the EDGE tables and I'm not sure how to (as you may not declare any columns). Cost wise, compared to a composite key table, this meant that the Graph Table query was higher. A Table Scan had to be performed on the EDGE table (NODE tables had Clustered Keys), while a Clustered Index Scan could be performed when using the "normal" tables. With a small amount of data, this was a minimal difference, but with much larger datasets, I can see it quickly slowing down.
How have others got along with them so far?
Edit: Ok, so Clustered Indexes look like they work well if created on the $from_id and $to_id columns.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
May 24, 2017 at 1:42 pm
Thom, I'm not sure I'm totally following you, and you are just now clueing me into graphs, but can you show me how you're comparing the graph syntax to the composite key syntax? Perhaps using the MS "friends" example? https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
May 24, 2017 at 1:54 pm
Played around with it, can honestly not say I see an immediate use for it in my own life, but considering other similar products are doing this, it just makes sense that MSFT introduces it into their product catalog.
Look at https://neo4j.com/product/ - they have it pretty much dialed in already.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
May 25, 2017 at 1:48 am
jonathan.crawford - Wednesday, May 24, 2017 1:42 PMThom, I'm not sure I'm totally following you, and you are just now clueing me into graphs, but can you show me how you're comparing the graph syntax to the composite key syntax? Perhaps using the MS "friends" example? https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview
I'm planning to do an article at some point, once work gets a little quieter as I've had a sudden influx, so hopefully then 🙂
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
September 23, 2017 at 4:44 pm
Itzik touches on the topic in this article... http://sqlmag.com/software-development/puzzle-challenge-graph-matching-t-sql-part-1-concepts
October 5, 2017 at 8:19 am
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply