That’s the problem that’s wrong?
No. Identity is designed to work with a nearly complete level of customization. Not only is it possible to define more User relationships with other entities, but even to change the table name in the database.
What are the problems in doing this?
To my knowledge, there is no problem in relating users with other entities of your system.
I feel like I’m mixing databasefirst with codefirst and I don’t really know if this is right or not, what problems can arise when having to move Fist code of the identiy classes?
If I understand, apparently you want to take advantage of a database that already exists with ASP.NET Identity. Then I would say that can be problematic. Explain:
ASP.NET Identity implements some features that your existing bank will hardly ever have, such as handling passwords. Unless your bank has exactly the same information would work smoothly, which is very difficult because other frameworks do not implement the same encryption scheme.
In this case, it is best to implement a schema of your own and not use Identity.
What are the problems when moving the columns of my ready-made database created via databasefirst?
It depends on several factors. A legacy system could stop working, for example.
For existing databases, it is not recommended to let the Entity Framework manage the database. The Database First does not manage the database by design.
I don’t see any problem in doing this, it uses codefirst for everything (I prefer at least) and changes the connection string from Identity to that of your database, it will already create everything there. (If you used the default template just do this) from there is to make relationships.
– Ricardo