Yo, DB folk

Malcolm · Post by **Malcolm** » Mon May 10, 2010 2:39 pm

Anyone doinked around with SQL Server 2008's HierarchyID data type ... specifically for storing trees?

Post by **TheCatt** » Mon May 10, 2010 2:52 pm

No, but I'm intrigued. What are you doing with it?

Malcolm · Post by **Malcolm** » Mon May 10, 2010 3:27 pm

We've got an arbitrary hierarchical tree that's stored in a DB in the standard way -- every row has a column pointing to the ID of the parent row. SQL Server 2008 has this new-fangled HierarchyId data type that's not only supposed to glue the tree together, but provide other bits of useful tree functions (insert, delete, etc.). We're deciding whether to keep the old way or go the new way.

DoctorChaos · Post by **DoctorChaos** » Tue May 11, 2010 8:05 am

This might be me being cynical, but I would avoid their new fangled toys since it probably won't work the same in the next release. Sorry, feeling a little crusty.

Malcolm · Post by **Malcolm** » Wed May 12, 2010 6:10 pm

Found a way to bullshit hierarchy IDs into playing nice with EF. If you store trees in a DB, this thing seems to be the way to go.

Post by **thibodeaux** » Thu May 13, 2010 11:47 am

Interesting.

Malcolm · Post by **Malcolm** » Thu May 13, 2010 2:41 pm

I spoke a bit too soon. I figured out a way to make EF take the data without problems. The operations are another story...

EF sees the corresponding C# type as untrusted & refuses to run any methods associated with it. It's not that hard to simulate that functionality yourself, though, if you really want to. If you search and return entire subtrees or need to fuck with your tree structurally, it's still the way to go.