Существуют различные виды наследования. Разработчики могут думать с точки зрения интерфейсов и поведения.
В вашем мире, что значит иметь "userType" администратора?
Семантика, на которую вы, вероятно, намекаете, состоит в том, что некоторый код где-то видит этот тип пользователя и разрешает действия для пользователей с этим типом. Так, может быть, администратор может создать других пользователей?
В этом случае разработчик может иметь класс User
class User() { viewData(){ ...} ; signReport() {...} }
и администратор класса с дополнительной возможностью
class Administrator() extends User { createUser() {...}; approvePurchase() {...} }
Объект типа Администратор может использоваться везде, где может использовать Пользователь. Это полиморфное поведение может быть полезным при реализации. Теперь ваша база данных вполне правдоподобно поддерживает этот случай. Однако что вы будете делать, когда администраторам понадобятся немного дополнительных данных для выполнения их конкретной задачи? Например, параметр purchaseApproval () имеет ограничение до определенного предела, этот предел нам нужен как новое поле, но он применяется только к администраторам.
Я считаю, что поведенческие аспекты, подразумеваемые вашей «типовой» концепцией, довольно часто связаны с дополнительными данными.