Это, безусловно, хорошая идея, поскольку вы нормализуете базу данных. Я сделал похожий дизайн в приложении, которое я пишу, где у меня есть таблица сотрудников и таблица пользователей. Пользователи могут быть из сторонней компании или сотрудника, поэтому у меня есть отдельные таблицы, потому что сотрудник всегда является пользователем, но пользователь не может быть сотрудником.
Проблемы, с которыми вы столкнетесь, заключаются в том, что всякий раз, когда вы используете пользовательскую таблицу, вы почти всегда хотите, чтобы таблица личных данных получила имя или другие общие атрибуты, которые вы хотели бы показать.
С точки зрения кодирования, если вы используете прямой SQL, потребуется несколько больше усилий, чтобы мысленно проанализировать оператор select. Это может быть немного сложнее, если вы используете библиотеку ORM. У меня недостаточно опыта с ними.
В моем приложении я пишу это в Ruby on Rails, поэтому я постоянно делаю такие вещи, как employee.user.name, где, если я их храню, это будет просто employee.name или user.name.
С точки зрения производительности, вы работаете с двумя таблицами вместо одной, но при правильных индексах это должно быть незначительным. Если бы у вас был индекс, который содержал первичный ключ и имя человека, например, база данных попала бы в таблицу пользователей, то индекс для таблицы людей (с почти прямым попаданием), так что производительность была бы почти такой же, как с одним столом.
Вы также можете создать представление в базе данных, чтобы обе таблицы были объединены для дополнительного повышения производительности. Я знаю, что в более поздних версиях Oracle вы даже можете поместить индекс в представление, если это необходимо для повышения производительности.