Здесь есть пара соображений: во-первых, мне нравится смотреть на пользователя / группу как на случай составного шаблона. Это четко соответствует требованию: вам часто приходится обращаться с совокупной и индивидуальной версиями сущности взаимозаменяемо (как вы заметили). Реализация составного в базе данных не так сложно. Если вы используете ORM, это довольно просто (наследование).
С другой стороны, у вас всегда есть возможность создавать структуры данных, которые в основном пусты. Вообще, это плохая идея. Таким образом, вы можете сказать: «Ну, в начале, у нас нет никакой информации о Пользователе, поэтому мы просто оставим все остальные поля пустыми». Лучше всего попытаться смоделировать фазы, как если бы они были частью FSM. Один из самых ясных способов сделать это в этом конкретном случае состоит в том, чтобы различать пользователей, учетные записи и некоторые другие более специфичные для домена объекты, например, Подписчик или Клиент. Затем я могу зайти и просмотреть с помощью пользователя, зарегистрироваться и создать учетную запись, а затем, когда вы захотите адрес и другую личную информацию, стать подписчиком. Это также подразумевает наследование, и у вас есть дополнительное преимущество, заключающееся в том, что вы можете иметь точное представление о населении в любое время, которое не требует глупых махинаций, таких как «SELECT COUNT (*) WHERE _ not null и т. д.