I have a class, suppose it's called EntityModel, and I want to make three different tables with the same columns, as defined in EntityModel. Let's call the tables tbPast, tbPresent and tbFuture. I want also to access them separetely in the Entity DbContext:
using (var db = new MyContext())
{
var element = db.Past.Find(id);
db.Past.Remove(element);
db.Present.Add(element);
db.SaveChanges();
}
The main purpose of having three tables is performance: the table will have millions of rows, and the most important is the Present, with dozens of rows. Most queries will be made in the Present table.
What is the best way to do this? Implementing three models with the same properties doesn't seem right for me.
I'm using Entity Framework, with the Code First approach, along with ASP.NET MVC 3.
You can't use the same model to generate separate tables w/ EF code-first. If you need to have some sort of grouping, use a Discriminator field and assing it any of the values: Past Present Future.
Edit:
Similar effect can be achieved through table-per-concrete type inheritance. Thus each type will have it's own table and can share most (if not all) of the fields.
Related
I have tables with the same structure but with a letter prefix of every table.
For example:
A_Company, B_Company, C_Company
There is combo box from which the user can select A, B or C, and then the code saves data into the appropriate table.
How can I do this using EF database-first?
I solved this problem adding a column for code prefix and triggers on my base table company for insert update and delete.
As the other commenters have said, it would be much better to refactor the database to a single table. If you can't do that then the only other thing that I can think of is to have a class which will select the table for you.
I would create a new class which has the same properties as your company tables, and also has the descriminator property. This would then be used as the data source for your ui.
in this class you would have to code manually to draw the data from the correct actual table (and save to it) based on the value of the discriminator. This is fine if you have only a few tables, but as your number of identical tables grows large, this will become more of a headache.
It might be possible to have the base tables all inherit from a virtual base class which would help a bit - you could then create a dictionary which the base class could use to switch the final data source on the fly.
As a final thought have you considered:
1. Creating the master table as suggested by the other commentators as a single table and then having views for each company.
Creating the master table as suggested and then having code to create the individual tables from that one at some point prior to their use?
I'm making an application that uses legacy database, using EF6 database first, .Net C#.
The database has two versions: the old and the new one. In the new one some tables were modified and renamed. E.g. old one has tables like: work, order, item etc. and new one work_t, order_t and item_t.
The content of corresponding tables is very similar, in the new ones some new columns were added and some were removed. So my application is supposed to work with both kind of databases as I use only the columns that are presented in both versions.
I was wondering if there is any decent way to hide those table pairs behind some interface or something to avoid doing 2 implementations of LINQ coding.
This is not exactly creating one entity out of 2 tables, because only one table is presented in the database at a time. I want to have single piece of code to address either one of the similar tables.
Here's some pseudo code for what I'm after:
public workDTO GetWork(int workId)
{
MyEntities db = new MyEntities();
// for old version it will go like
var work = db.work.Where(a => a.id == workId);
// for new version it will go like
var work = db.work_t.Where(a => a.id == workId);
return Mapper.Map(work, workDTO);
}
So the idea is to have just one method and one LINQ implementation for both tables.
Yes , You can do it by giving a column attribute in entity framework:
Read here
Update :
You can use the .ToTable() method:
modelBuilder.Entity().ToTable("t_Department");
Source: MSDN: http://msdn.microsoft.com/en-us/data/jj591617.aspx
In order to populate Dropdownlists, showing the details rather than id on Gridviews (showing City name instead of Birt city id), etc., sometimes we need to retrieve data at the same time from Master (for ex. Student) and Detail (for ex. City) tables. Could you suggest me which scenarios below is the most suitable? In addition to this I would be appreciated if you suggest other approaches provided that using Entity Framework.
1) I retrieve data from Entity tables and I use relations between master and detail tables. But in that case I need to define these relations on my DbContext and I have to populate dropdownlists by methods. But for displaying data I need to define another methods or etc. For this reason actually I do not like this approach. What do you think for this?
2) Instead of this I can use ModelView as I had used before. But, I think it is not good idea return more tables instead of one table lots of times. In addition to this, I think I need a extra definition for dropdownlist for example in an htl helper. I think it is also not handy.
3) As it is used commonly, I think getting data from entity views (database view) instead of entity table seems to be very useful. With the help of this approach, I can retrieve data from 2 tables and I can easily show this data on dropdownlists and grids without an extra effort. What do you think?
a) On the other hand, if I use a view entity instead of table entity, how can I save this entity to the database (normally I return table entity for creating/editing).
b) If this method is good, in that case I think I need extra entity definitions for the related database views in addition to the tables. For example I have Student, City entities now. But for the database View I need another 3rd entity. Could you give me a usage example for this approach?
BR.
If I have for example two entities, lets say Customers and Staff with no relation between them, is it possible to create a third entity which doesn't have a corresponding table in the database which takes some information from the first and the second entity and also one or two additional columns (for example computed columns)?
You can join entities through this: http://blogs.msdn.com/b/simonince/archive/2009/03/23/mapping-two-tables-to-one-entity-in-the-entity-framework.aspx
But I do believe they have to be related; otherwise, how would it know what information was correctly tied to each other? The only thing it could do is query all rows of one entity and match them up with all rows of the other, which is probably not what's desired.
I am trying to come up with a database design that would work with Entity Framework 4 Code First. Actually, I have no experience yet of EF4 Code First but as I understand it, if I write the code, it will create the database and tables.
The issue is this. There are various types of auctions, they all have some common fields and some specific ones. In the code I envisage having a base abstract class called Auction and subclasses like LowestUniqueBidAuction and EnglishForwardAuction etc.
Nothing surprising there. The problem is that I imagine the database structure to mimic this. I imagine an Auction table and a LowestUniqueBidAuction table and a EnglishForwardAuction table. In the Auction table I imagine a foreign key into one of these two tables for each row depending on the type of auction that that row is. I also imagine another column in the Auction table with the name of the derived auction table (such as EnglishForwardAuction).
The problem is that whenever I've ever created a foreign key I've had to specify the name of the foreign table into which the key points (which makes sense). In this case, however, there is one of many tables that the key could point. So there are many issues here. Firstly, I could simply not use a foreign key and just use an ordinary field, but then the database will not be able to maintain data consistency for me. The second issue is how will EF Code First handle this? In other words, how will it know that if I ask for all EnglishForwardAuction rows from the Auction table that it should look at the column with the table name and then join on the EnglishForwardAuction table to get the extra fields?
Has anyone ever faced similar issues?
Thanks,
Sachin
This problem is solvable in Entity Framework in a number of ways - read up on how EF handles inheritance and what strategies are available.
There are basically three strategies how to handle this:
(1) Table per Hierarchy
You have only one single table, that represents all possible sub classes. Of course, this means, several rows (that only exist in a given subclass) must be nullable, since they don't show up / don't exist in super classes or other subclasses.
(2) Table per Type
Each subclass gets its own table, and by default, the sub-types table shares the PK with the base classes' table - e.g. PK = 1 in Auction will also be PK = 1 in EnglishForwardAuction. So your subclass tables reference the base table - not the other way around.
(3) Table per Concrete Type
Each concrete subclass (your separate auction types) gets its own table, but that table contains everything - all the columns, from that specific type, but also its base type.
Read more here:
Inheritance in the Entity Framework
Inheritance and Associations with Entity Framework Part 1
Entity Framework Modeling: Table Per Hierarchy Inheritance
Entity Framework Modeling: Table Per Type Inheritance
Searching for Entity Framework Inheritance and/or one of these strategies will reveal a lot more hits, too - that topic is very well covered and discussed on the interwebs! :-)