I am migrating from ASP Membership to ASP Identity authentication. In this article from travis.io, Travis migrates some of the ASP Membership fields to a side table that he created and named AspNetUsersExt (fields like security question and answer to reset password for example). I don't see why he would do that because these fields have a one to one relationship to the user. I could understand if his application is using fields that are one to many to the user, but if you are just using LastLoginDate for example then why not just bring that field over to the actual real users table (AspNetUsers)?
Below are the only quotes from him to explain why he is using this side table:
"This is a custom table, and I use it to store additional details from the Membership tables which allows me to keep the [AspNetUsers] table clean and simple."
"As much as possible, I wanted to preserve the vanilla implementation of IdentityUser, the model that ASP.NET Identity uses, so any of the additional data from the old Membership tables that I did keep is stored in a separate table."
I am thinking it would be easier to just migrate ASP Membership fields like these to the real users table (AspNetUsers).
Is there a best practices reason to create a side table to keep AspNetUsers "clean" or "vaniila"? Perhaps something to do with future-proofing the data for future updates or changes made to Identity itself? Am I missing something here?
Thanks for your reply!