实体框架是否适合更大的数据库？ [英] Is Entity Framework good for bigger Database?
问题描述
但是，只是为了看一个更大的数据库在数量上会发生什么表/实体我试图将实体框架实现到具有大约100个表的数据库。
一旦我选择了所有的表并点击了实体框架向导上的完成按钮，它刚刚挂起了我的VS 2010，所以我无法得到任何结果。
我的问题如下：
1.如果我有如上所述的Table / Entites的数据库较大，使用Entity Framework是个好主意？ p>
2.使用实体框架来处理数据库会更好吗？
3.我要创建多个DataContext或EDMX文件中有较少的内容？
4.这些不同的DataContext如何互相交流？
5.在使用Entity Framework时，是否应该使用任何建议使用的表格？
@Will是正确的你看到的限制是在设计师，但它不是唯一的，所以Code-First不一定能解决问题。
如果设计师看起来很慢，这是不方便的，但不是世界的尽头。 运行时性能注意事项是另一回事。对于性能关键任务和调优，您将需要了解整个管道。
查看生成，例如需要时间。您可以通过手动工作将其移动到编译时间。
1.如果我在Table / Entites中有更大的数据库，如上所述，使用Entity Framework是个好主意？ / p>
我当然不会让它阻止你。
2.使用Entity Framework处理数据库的更好的方法是什么？
3.我要创建多个DataContext或EDMX文件吗？
这对许多人来说肯定是一个很好的方法应用程序。
4.这些不同的DataContext如何相互交互？
多数不是。 一个单一的，由于服务耦合，巨型数据模型往往是一个坏主意。但是，您可以通过共享EDMX中包含的部分模型或以代码优先的方式来选择性地耦合它们。
5.在使用Entity Framework时，是否有建议使用的表格数？
方法是使用较小的型号，如您所建议的。另一种方法是解决运行时性能问题，这些问题有时候会使用更大的型号（请参阅上面给出的链接）。像任何潜在的性能问题一样，首先编写正确的代码，然后配置文件并修复缓慢的部分。通常，查询调整比模型大小更重要。
I used Entity framework with a database having around 50 tables and it worked just fine.
But just to see what happens with a larger database in terms of number of tables/entities i tried to implement the Entity Framework to a database that had around 100+ tables. Once i selected all the tables and clicked on the Finish Button on the Entity Framework Wizard its just hanged my VS 2010 so i could not get any results.
My Questions are as below;
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
4.How will these different DataContext interact with each other?
5.Is there any recommended no of tables that should be used while working with Entity Framework?
@Will is correct that the limitation you're seeing is in the designer, but it's not the only one, so Code-First doesn't necessarily fix the problem.
If the designer seems slow, it's inconvenient, but not the end of the world. Runtime performance considerations are another thing altogether. For performance-critical tasks and tuning, you'll want to understand the whole pipeline.
View generation, e.g., takes time. You can move this to compile time with manual work.
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
I certainly wouldn't let it stop you.
2.What will be the better approch using Entity Framework to work with database? 3.Should i create multiple DataContext or EDMX files with lesser entites in it?
That's certainly a good approach for many applications.
4.How will these different DataContext interact with each other?
Mostly not. A single, giant data model is often a bad idea due to service coupling. However, you can selectively couple them by sharing portions of the models with includes in EDMX or classes in code-first.
5.Is there any recommended no of tables that should be used while working with Entity Framework?
One way is to use smaller models, as you've suggested. Another way is to work around the runtime performance issues which sometimes come with larger models (see the links I give above). Like any potential performance "problem", write correct code first, then profile and fix the slow parts. Usually, query tuning is more important than model size anyway.
这篇关于实体框架是否适合更大的数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
