Добрый вечер всем!

У меня есть 2 типа пользователей, которые могут регистрироваться на сайте.
Клиенты (у них своя форма регистрации и свой профиль) и компании (другая форма регистрации и совершенно другие поля).
Но оба они с точки зрения администратора системы являются пользователями.
Как правильно спроектировать базу данных?
MySQL - InnoDB (есть внешние ключи).

Таблица user, client и company, где в user хранить логин и пароль, а в остальных таблицах хранить все поля, которые нужны каждому типу пользователей + в качестве Primary key хранить user_id в таблицах client и company и связь с таблицей user как 1 к 1му?

В этом случае единственным вопросом (хорошо ли это) остается отсутствие автоинкремента и "дырки" в PK в таблицах client и company.

Или может другая архитектура нужна?

Кот МатроскинНасчет трех таблиц - нормальyая схема. (если Вы совершенно точно уверены, что никогда-никогда одной компании не потребуется нескольких регистраций).
Делать ли user_ID первичным ключом в Client и Company - философский вопрос. Проблемы в "дырках" я не вижу вообще никакой, проблема имхо в другом - это разные сущности с разным жизненным циклом. Например, клиент зарегистрировался у Вас 1 раз, потом регистрацию удалили, потом он регистрируется второй раз - Вам придется создавать еще одну запись в client, теряя всю историю по прошлой регистрации.

Имхо лучше все-таки сделать отдельные первичные ключи в таблицах client и company, и оставить nullable-ссылку user_id
Спасибо за ответ!

Думаю, что если клиент потеряем свои доступы он все равно заново будет регистрироваться, поэтому это не настолько серьезная проблема))

А вот что касается отдельных PK в таблицах client и company - я действительно думал, но в таком случае получается отношение 1 ко многим, т.е. один User может стать Двумя клиентами и с точки зрения схемы БД это будет правильно.
Но я понимаю, что на серверной части можно не предусматривать такой функционал, и такого не будет никогда.
Интересовало best practices и возможные подводные камни этих 2х решений.

Максим Нkezmanотсутствие автоинкремента и "дырки" в PK в таблицах client и company.

Это как?

Буду ли дырки в PK или не будут, это от вас зависит.

А так нормальная схема.

В случае такой схемы дырки в PK будут в таблицах company и client и от меня это не зависит)
Т.к. сначала пользователь регится и создается запись в таблице user.
А затем он выбирает - компания он или клиент.
Выбрал компанию.
Следующий юзер выбирает клиента.
Третий юзер выбирает компанию.
Получается, что в таблице company строчки с PK - 1, а потом сразу 3.
Это и есть дырка.
Проблема действительно не серьезная, вероятнее ее вообще не стоит даже проблемой называть, но упомянуть для целостности картины стоило.

Кот МатроскинkezmanДумаю, что если клиент потеряем свои доступы он все равно заново будет регистрироваться, поэтому это не настолько серьезная проблема))

Вот именно - клиент-то будет регистрироваться заново, но у системы будет возможность
обнаружить, что человек-то на самом деле тот же самый, создать новую запись в User,
но привязать ее к старой client (убив старую ссылку).
Делая первичным ключом userid - Вы жестко связываете в системе сущности, которые в
реальномо мире, вообще говоря, связаны не очень жестко. Если считаете что абстракция,
лежащая в основе Вашей системы, от такого упрощения не пострадает - Вам виднее.
Имхо выигрыша от такого решения немного (на одно поле меньше в таблицах), а ограничения на развитие системы - появляются.


kezmanА вот что касается отдельных PK в таблицах client и company - я действительно думал, но в таком случае получается отношение 1 ко многим, т.е. один User может стать Двумя клиентами и с точки зрения схемы БД это будет правильно.

Если Вас это смущает - можете повесить Unique constraint на поле userID в таблицах Client
и company, тогда все будет предусмотрено прямо в схеме.

Спасибо большое за аргументированный ответ и ценное инфо!!!
Действительно ограничения на развитие системы это не айс, а проблем с доп. полем нет, конечно же))))))))))
Сделаю именно так!