This has been asked a lot in the past, and I know that there was no direct support for setting a field as indexed in the EDMX designer, but since Visual Studio 2012 is out and Entity Framework 5 is released, it may now be supporting editing indexing options in the designer (no reason for it not to support it anyway), I've looked at the properties of fields and all I can find is to set a field as entity key but it doesn't solve my issue (I already have an entity key, I just want to create indexes on some other fields for performance reasons).
How do I set a field as an indexed column in the EDMX designer? (I know how to do it after via SQL queries, but I need a more modular approach as I'll be editing the database and recreating it and I will most likely forget to add an index every time by an SQL query).
Thanks,
Can.
Unfortunately things have not changed in VS2012 in this area. I would encourage you to open a work item on EF6 codeplex site
Related
I would like to recreate a 10 years old application with newer Technologies like ASP.NET WebAPI, AngularJS and the EF. Unfortunately, I have to stick to the existing database as the new webclient will run parallel with the existing one.
The difficulties:
- Some tables are cleared and refilled with data from other systems every week
- Many tables are referencing each other on non-primarykey fields.
- A lot of the Update/Write logic has been done with stored procedures so far.
Because of the first two things I am not able to use navigation properties when I just create an .edmx Diagramm from the existing db model. The only Workaround which came to my mind, is to use views (updatable views) for the tables without primary keys and just add the missing primary key field to the view.
Unfortunately, all changes made to the .edmx file have to redone whenever I update it from the model.
Is there any better solution? Does it even make sense to work with EF when using a database like that? I would probably still like to go this way because I could at least improve my EF knowhow.
Our database has about 500 tables we'd like to use in our EF model. Of those I'd be happy to start with 50 or fewer just to get our feet wet after working in plain ADO.net for years.
The problem is, our SQL server contains many thousands of other tables that exist in our database that have been created through the years and many that are dynamically generated. Believe it or not:
select count(*) from INFORMATION_SCHEMA.TABLES
73261
So that's a lot of tables. I have found that pretty much every tool I've tried to design, build or template EF models or entities either hangs or does not return a list of tables. Even SQL Server Object Explorer in VS2012 won't list the tables and instead shows the Tables folder with a little "x" over the icon. So I can't even select a subset of tables.
What options do I have for using EF? Is there a template where I can explicitly define the tables that I want to use entities for? Even with 50 tables, I don't want to hand code each one in an empty EDMX.
Using a Database / Code First approach and avoiding connecting Visual Studio to the database at all (i.e. don't create an edmx, or connect with server explorer) would allow you to do this easily. It does not give you any of the Model First advantages, but I think it sounds like your project would be better served with a Database / Code First approach anyway as:
You have an existing Model, and are not looking to push changes from your EDMX to the DB
You are looking to implement this on a subset of your database
This link has a good summation ( Code-first vs Model/Database-first ) with the caveat that in you case a Database/Code First approach does not have you pushing changes from code to the Database, so the last two bullets under code first apply less, and yours is a Database/Code First hybrid.
With 70k tables I think that any GUI is going to be tricky. When I am saying Database / Code First, I am trying to convey that you are not using the code to create / define and update your Database. Someone may be able to answer this more succinctly / accurately?
I now this is an old question. But for those who land here on a google search. The only tool I have found that actually works with thousands of tables is The Sharp Factory.
It is an ORM. Pretty simple to use. So if you are looking for an ORM that can work with a large number of tables and does not require you to write "POCOS" or "Mappings" or SQL then this is the tool.
You can find it here: The Sharp Factory
Is there a way to tell EF not to update SSDL for the single table when doing Update Model From Database?
A little more details:
We're using EF 4.3 with Db-first approach (so, edmx and Update Model From Database).
We have a table that for some reasons does not have a primary key set in SQL Server, but have an auto-incremented Identity column that we can tell EF to use as primary key.
Since EF isn't finding any primary key in a table itself, it generates a DefiningQuery in SSDL for that table (and prevent update/inserts).
I can easily delete that DefiningQuery (and modify other EntitySet attributes) and everything works fine.
Except when I do another Update Model From Database that DefiningQuery is back again.
Is there a way to tell EF not to update SSDL for that single table?
Is there a way to tell EF not to update SSDL for the single table when
doing Update Model From Database?
Not with default designer provided in Visual Studio. Once you modify SSDL part of your EDMX file you should maintain it manually or write a script which will fix it every time you run Update from database.
Alternatively you can buy more powerful designer or extension to Visual Studio which will offer you selective update.
Anyway what you are trying to do should be avoided. If the database is owned by ERP you should do the access only through ERP programming API (real ERP has some). Otherwise you can break functionality of your ERP, corrupt ERP data, cause performance issues or even cause deadlocks.
Trying to wrap my head around the best approach in modelling a database when we are using Entity Framework 4 as the ORM layer. We are going to use asp.net mvc 2 for the application.
Is it worth trying to model using the class diagram modeller that comes with Visual Studio 2010 where you graphically configure your models into the EDMX file and then generate out the database structure?
I have run into a bunch of non trivial issues and for complex many to many mappings or multi primary key entities the answer is not that obvious even after poking around a while with the tools.
I figure its easy at this point to give up and start modelling the DB using real, working DB modelling tools and then try to generate out the EDMX from the database, rather than trying to do the model first approach.
It's really a matter of preference. If you are comfortable in SQL server that's probably the best place to start. But if you are more of a C# programmer, it's sometimes easier to start in the EDMX designer, make the model and then ask it to figure out what the database should look like.
Of course if you do go model first you'll still need to go in to SSMS and add indexes and maybe rename some FKs and tables more to your liking. Then you can bring the model back up to date with an Update from Model.
Modelling inheritance is also something you'll need to do in the designer, but again you can either do it in SSMS or in the EDMX designer. For inheritance I mostly prefer SQL first because there is the explicit decision as to what form of inheritance you want - per hierarchy, per class, or per concrete type.
I am starting with the Entity Framework. It sounds great. But I am wondering if I should watch out for some weakness somewhere. Any experience there?
You probably need to start prefixing these questions with the version you are talking about. A good amount of the annoyances have been fixed in the upcoming version in .NET 4.0.
Here is what I would say after working with the first version for about 6 months using a decent size DB in sql 2k8(40+ tables, several tables with close to 1M rows, and decent amount of traffic)
Lack of Foreign key properties. Meaning if I want to know or work with just the id of a related table I have to load the actual entity. (fixed in next version)
Utter lack of an easy outer join like linq to sql has when using DefaultIfEmpty. Fixed in next version.
Generated Sql is less than optimal This seems to be fixed in next version as well
Very difficult to abstract from your code for testability and for use in multi tiered environments, but it can be done. This can also be classified as the POCO problem that also has been resolved.
There are more, but these are my top ones.
Overall I would use it again, but if you are starting from scratch please save yourself some pain and wait for the latest version or start using the beta if you can.
You might find the walkthroughs for Entity Framework 4.0 useful. All of the new features discussed are annoying emissions from the currently released version for someone.
I found the new TDD/testability features and T4 code generation features especially interesting.
About EF1:
Generated SQL is horrible. It multiples joins, it is 10x bigger than it could. I had a simple query, but with a lot of joins and generating this query by EF (not executing) was slowing down significantly my application. No, I couldn't use precompiled query. I used view to cope with it. SQL Profiler was helpful.
Primary keys in views are not recognized properly. You have to change edmx file by hand when you import view or doing schema refresh.
You can design entities from database in graphical manner, update model from database, but it doesn't always work good, specially when you change field types or foreign keys.
You can't update one table in model, always have to update whole model from db.
You can't define base class for your entities, it is already defined (EntityObject). You can use interfaces, because classes are defined as partial.
No POCO, entity classes are strongly connected to framework.
You can set foreign key by EntityReference.EntityKey, but when you have EntityCollection, prepare for round trip to db. Or am I missing something?
I am finding the POCO objects and model-first design in the EF4 beta very sexy.