views:

1504

answers:

3

I'm working with a large hierarchical data set in sql server - modelled using the standard "EntityID, ParentID" kind of approach. There are about 25,000 nodes in the whole tree.

I often need to access subtrees of the tree, and then access related data that hangs off the nodes of the subtree. I built a data access layer a few years ago based on table-valued functions, using recursive queries to fetch an arbitrary subtree, given the root node of the subtree.

I'm thinking of using Entity Framework, but I can't see how to query hierarchical data like this. AFAIK there is no recursive querying in Linq, and I can't expose a TVF in my entity data model.

Is the only solution to keep using stored procs? Has anyone else solved this?

Clarification: By 25,000 nodes in the tree I'm referring to the size of the hierarchical dataset, not to anything to do with objects or the Entity Framework.

A: 

Everything IS possible with Entity Framework but you have to hack and slash your way in to it. The database I am currently working against has too many "holder tables" since Points for instance is shared with both teams and users. Both users and teams can also have a blog.

When you say 25 000 nodes do you mean navigational properties? If so I think it could be tricky to get the data access in place. It's not hard to navigate, search etc with entity framework but I tend to model on paper then create the database based on how I want to navigate while using entity framework. Sounds like you don't have that option.

mhenrixon
Thanks. In my scenario, the hierarchy (tree) is modelled with just a single table, in which each row holds data about the node and its parent node ID.
jamesfm
+2  A: 

It may the best to use a pattern called "Nested Set", which allows you to get an arbitrary subtree within one query. This is especially useful if the nodes aren't manipulated very often: Managing hierarchical data

In a perfect world the entity framework would provide possibilities to save and query data using this data pattern.

Georg Wächter
A: 

Thanks for these suggestions.

I'm beginning to realise that the answer is to remodel the data in the database - either along the lines of nested sets as Georg suggests, or maybe a transitive closure table, which I've just come across.

That way, I'm hoping to get two key benefits:

a) faster querying aginst arbitrary subtrees

b) a data model which no longer requires recursive querying - so perhaps bringing it within easy reach of the Entity Framework!

It's always amazing how so often the right answer to a difficult problem is not to answer it, but to do something else instead!

jamesfm