The Users in my database will be related to many other entities. Is the recommended practice for doing this to have 1 db context for the app? Or, should there be two different ones. It seems that I could retrieve the context through the use of the GetOwinContext()
-
possible duplicate of https://stackoverflow.com/q/19902756/ – Kahbazi Aug 17 '17 at 07:33
-
Possible duplicate of [ASP.NET Identity DbContext confusion](https://stackoverflow.com/questions/19902756/asp-net-identity-dbcontext-confusion) – trailmax Aug 18 '17 at 15:48
-
One context is easier to maintain. I've tried with 2 separate contexts and it just added maintenance overhead - think of migrations. – trailmax Aug 18 '17 at 15:49
1 Answers
The standard practice with this is to keep all of your tables for your webapp in 1 database (1 context). One large advantage of this is that you can execute SQL joins based on data that is stored in your Identity tables.
Here is a use case: I have a fileupload entity and table which I need to relate to a specific user (the user that uploaded the file). If everything lives in one database then I can use foreign keys and entity framework navigation properties as I normally would. If I was using a separate database/context for the Identity provided tables, then I would need to query two different database (which is more costly performance-wise) to get my needed data. One query to DB1 to get my user Id and another query to DB2 to get the fileuploads which belong to this user Id
So in short, if you have users related to many other entities (which you mentioned) then I would strongly recommend using 1 database and context.

- 5,125
- 8
- 55
- 109