Question

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.

Was it helpful?

Solution

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 MySQL.

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

OTHER TIPS

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.

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!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top