I have the following scenario:
I have a production database which is highly transactional. In order to keep queries efficient I would like to archive data from some of the tables to another database with exactly the same schema.
The relationships between tables are not very complex but any dependent objects would have to go with the archived data in order to uphold foreign key constraints.
Is there a simple way to do this using Entity Framework? I have tried to create two different contexts and add to one and delete from the other, but this is a bit of a tedious route.
If Entity Framework is not the best tool for this what is?
There is no simple way in EF5 to do this.
If your database is MSSQL you can make use of partitioning for archive tables (see http://blogs.msdn.com/b/felixmar/archive/2011/02/14/partitioning-amp-archiving-tables-in-sql-server-part-1-the-basics.aspx for more information).
Related
I am having an issue with my website(ASP.NET, c#, SQL, Code-first Entity Framework).
I have a project with an attached SQL database generated from code first entity framework.
Now I have imported another SQL database using model first database which looks almost same but the table and column names are different.
So now I would like to write data to two databases at the same time with just one click from my web application.
The newly attached database will be a backup and we should write data to both databases at the same time.
Any suggestions would be highly appreciated.
Thanks
As others have suggested, you need to do the mapping yourself, but one thing I would like to add, you may need to wrap your SaveChanges() into a transaction, you may find steps here: https://msdn.microsoft.com/en-us/data/dn456843.aspx
I would like to add new module (project) to my solution and to use entity framework code first only for subest of my database tables. I'm using ADO.NET with stored procedures in other modules. I plan to split tables from db in the future, but for now it is not possible (tables have no relations to other tables but are used by old modules) I'm not sure if it is good practise to do it in this way and I would like to ask for help.
is it possible to use EF code first for subset of the tables of my DB?
how to initialize these tables with code first? I found only solutions to drop whole
db if model doesn't match and recreate new DB. I need drop and recreate only
tables that are used in my project
is it good practise to use more approaches of the db access to one db?
do you see some problems in this approach? Now I see problem with concurency and data consistency ( if old module will operate with this tables in another approach )
Thank you.
1) Yes, it is. On one of our projects, we had database with store procedures which we migrated to use EF. But not at once. It had taken some time so we used Store procedures whit ADO.NET as well as EF together.
2) I must say I'm not sure about this. We had database already created with only few changes. But you could created tables by yourself.
3) I think better would be to call stored procedures from EF and use it on whole projects if you need them. But using both, ADO.NET and EF is ok, if you have reasons.
4) Why it would be problem if you will use transactions?
My situation is as follows. I'm using entity framework (4.0) in which I have defined a relatively simple model like, let's say, two entities:
user
transaction
A user can have multiple transactions in this scenario. When generating the database this would result (obviously) in 2 database tables names 'user' and 'transaction'.
The problem is that I want to use the code as a webservice where different companies should have their own environment (read: own users and transactions). A simple solution would be to add a column to both tables like, lets say 'company_id' to identify one user/transactions for companya from the user/transaction from companyb.
What I would like to have is a duplication of the tables like so:
compa_user
compa_transaction
compb_user
compb_transaction
This way..all data would be nicely separated and if company a generates a lot of transactions, company b would not notice that the system is getting slow or whatsoever.
My question: is there a way to accomplish this based on entity framework. So, can I have multiple tables representing one entity in my model and switch from table to table depending on which company is connecting to the service.
Any help appreciated!
If you really want to keep the tables seperate, then a seperate database for each client would be the easiest - only need to change the connection string in EF.
The other benefit of this model (seperate databases) is that the database will scale quite easily as each database could theoretically be on a different database server should the DB ever become the bottleneck.
I'd like to know how to (if possible) associate tables from different databases using entity framework. I have one edmx for my "xyz" database and another for my "abc" I need to associate them using EF. I know how to fix this using FKs, but that's not what I want, I'd like to be able to do that using the visual editor, not adding, by hand, a FK to my DB.
Here's a pratical example of what I'd like to accomplish:
Table User - database: abc
Table Message - database: xyz
I'd like to associate User to Message and vice-versa.
Could anyone help me?
Thanks!
You can query them together with Linq-to-Objects, but not with L2S or L2E.
A context is wrapped around 1 Db-connection, you cannot track/update entites from multiple db's.
A possible workaround is to 'link' to one of the Db's from the other. MS-SQL can do this. To the EF it would appear 1 database.
There is no way to achieve this using the edmx design surface in EF.
You could encapsulate this association within your domain model and provide a distributed transaction across the two EF Contexts. We've implemented the latter with an EF Context "container" class that given an internal collection of contexts uses a TransactionScope when it contains more than one context (this relies on the IUnitOfWork abstraction to work effectively).
I am reading the Entity Framework 4.0 recipe. In chapter 2, it has a bunch of recipes for modeling our entities relationship ( Table per Type, one to many, ...) basing on the relationship table.
My question is that EF will automatically create models to match our database tables relationship already. So why do we need to remodel our entity models again even though that won't change our database scheme and tables?
Note: I am using an existing database scheme and don't want to change any relationship from the database.
Well that's is the whole idea of Entity Framework that a conceptual model is how we portray or perceive the business looks like. However the data is stored usually in 2nd or 3rd normal form to make efficient use of disk space and also improve the efficiency of data retrieval. To make both worlds happy, we consume the best of both worlds and apply modeling on top of it mask the conceptual model into the storage model.
If you business model is exactly similar to how you store your data in the database, then you do not need to remodel it.