Does Entity Framework work well for large db with 800+ tables?

I have 869 tables in a database. I'm sitting on the fence as to which way to swing -- EF (version 4) or plain old ADO.NET, with a mild incline towards Entity Framework. I am only worried whether the Entity Framework model designer will freeze at such a large data model and if it will be a nightmare to maintain.

Have any of you tried using Entity Framework with such a large data set?

I have some databases with a lot of tables and not had a problem, but not 800 of them.

but do you need one model with all the tables at one time ?

with most projects I only need to reference a few tables  from the db , we have say 20 sets of web services and many of them have models that only use say 10 or 20 tables out of say 100 or so.

EF does not force you to import every table.   so just add the ones you need, you can add more of them later if you need to.

@Sathyaish Chakravarthy: Well, given the lack of response so far, I guess there's only one way to find out ...

Let us know what happens

Herbie

If you absolutely have to have a model with lots of tables, EF5 lets you split your model into multiple EDMX files. It's still one model, but multiple designer files.

However, as was said, you most likely don't need all of those at once.

2 hours ago, kettch wrote

However, as was said, you most likely don't need all of those at once.

Whatever the result, the issue is not with EF. Sounds to me like someone went mad with denormalisation.

Conceptually how you deal with a model with 800 classes is going to be hard, you would be best to group the tables by functionality, or refactor the database if it is young

Definitely have multiple edmx files or go code first. My edmx designer regularly crashes and is awfully slow with only 50 or so tables.

19 hours ago, Dr Herbie wrote

@Sathyaish Chakravarthy: Well, given the lack of response so far, I guess there's only one way to find out ...

Let us know what happens

Herbie

Thanks, Dr. Herbie. I was thinking along the same lines actually.

21 hours ago, kettch wrote

If you absolutely have to have a model with lots of tables, EF5 lets you split your model into multiple EDMX files. It's still one model, but multiple designer files.

However, as was said, you most likely don't need all of those at once.

Thanks much, kettch. That's probably an answer to my problem. I am going to do just that.

18 hours ago, vesuvius wrote

*snip*

Whatever the result, the issue is not with EF. Sounds to me like someone went mad with denormalization.

Conceptually how you deal with a model with 800 classes is going to be hard, you would be best to group the tables by functionality, or refactor the database if it is young

As in most real world situations, the database comes as a given to me from the year 14 B.C. It was first created then by the Barbarians and then immediately dropped as it was too heavy a load for them to carry.

Activity on it resumed a couple of a hundred years later when King Chatushpada of the Mauryan empire defeated the Mughals in Delhi and began his reign. Right then, on another side of the world, some people were busy finding Columbus while he went to find a piece of land.

Our beloved database came back to life precisely then. This time, when the year was 1497, it was graciously re-created, and in a spur of kindness, left over in posterity by a dozen or so excited African monkeys who recorded their observations of Lord Kelvin as he sailed through the Atlantic collecting a variety of rocks.

You're right. Someone went mad. But it wasn't me.

A hint of relief, albeit just a hint, is that there's a lot of junk tables in the database and I probably won't be needing about half of them. But still, even a half of them are as strong as the whole.

25 minutes ago, Sathyaish Chakravarthy wrote

*snip*

As in most real world situations, the database comes as a given to me from the year 14 B.C. It was first created then by the Barbarians and then immediately dropped as it was too heavy a load for them to carry.

Activity on it resumed a couple of a hundred years later when King Chatushpada of the Mauryan empire defeated the Mughals in Delhi and began his reign. Right then, on another side of the world, some people were busy finding Columbus while he went to find a piece of land.

Our beloved database came back to life precisely then. This time, when the year was 1497, it was graciously re-created, and in a spur of kindness, left over in posterity by a dozen or so excited African monkeys who recorded their observations of Lord Kelvin as he sailed through the Atlantic collecting a variety of rocks.

You're right. Someone went mad. But it wasn't me.

A hint of relief, albeit just a hint, is that there's a lot of junk tables in the database and I probably won't be needing about half of them. But still, even a half of them are as strong as the whole.

LOL .... I worked on one system and I always tell folks the DB diagram they printed out looked like one of the micro pictures of a CPU with so many lines going all around and tiny blocks.

1 minute ago, figuerres wrote

*snip*

LOL .... I worked on one system and I always tell folks the DB diagram they printed out looked like one of the micro pictures of a CPU with so many lines going all around and tiny blocks.

That's still something. I'm worried mine might look like a swarm of worms on top of each other having sex.

23 hours ago, Dr Herbie wrote

Let us know what happens

20 hours ago, vesuvius wrote

Whatever the result, the issue is not with EF. Sounds to me like someone went mad with denormalisation.

Denormalization would reduce the number of tables.

@Jim Young: Correct, I meant normalisation, but he does also need to denormalise.