Это зависит на уровне абстракции, в которой Вы работаете.
я знаю, что у меня есть подобный опыт, как Вы делаете. На текущем уровне абстракции большей части разработки программного обеспечения. Словарь и Список являются основными структурами данных, которые мы используем.
я думаю, смотрите ли Вы вниз на более низкий код уровня, Вы будете видеть больше "экзотических" структур данных.
Это разделение управления идентификацией / аутентификацией от управления членством. «Большая» пользовательская таблица - это фактическое хранилище идентификационных данных - например, если вы хотите использовать SQL для хранения ваших идентификационных данных, все это входит сюда. Но вы можете захотеть использовать какой-нибудь другой источник, например Active Directory, в качестве репозитория вашей личности. Вместо этого вы проверяете идентичность и аутентификацию, но вам все равно нужен способ присоединить данные роли / членства на основе SQL к данным идентификации на основе AD. Вот тут-то и пригодится меньшая таблица - информации ровно столько, чтобы поддерживать эти отношения.
Это для защиты нескольких приложений из одной пользовательской базы данных; aspnet_membership имеет UserId и ApplicationId, поэтому каждый пользователь может иметь разные пароли для нескольких приложений (а также быть заблокированным для одного приложения, но не для другого).