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.
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does :-P
Please always remember to encapsulate your code in IFCode Markup. For example [code=sql] [/code]
to read Jeffs Guide on how to post SQL questions, and get swift and helpful answers from the community