Как правльно создать таблицу пользователей двух типов в БД?

Две таблички делай и форейн ключ по ІД юзера.

Первая таблица: id, first name, last name, email, password, type/role Вторая таблица: id, company, upn

По ID можешь привязать компанию к юзеру, а по type/role фильтровать потом.

Юр. лицо - это не физ. лицо. У них общего - только слово «лицо». Директора юр.лица появляются и исчезают. Так же и юр. лица закрываются и открываются на одних и тех же людей. И я тебе даже больше скажу, фио может меняться и его update делать нельзя.

Первая таблица users (id, first_name, last_name, email, password, role, type)

Вторая таблица companies(id, name, unp)

Третья таблица employees(id, user_id, company_id)

Паспортные данные отдельно с датами актуальности (или вообще в отдельной сертифицированной бд и это - НЕ mysql, см закон о ПД) Роли - отдельная таблица. Ну, если у тебя это - не студ. поделка.

создать только одну таблицу accounts и там, где у юзера будет >роль = «Физическое лицо» заполнятся null поля, которые должны >быть заполнены у компании,

Вот это.

Кроме того, можно полюбоваться примерами оверинжиниринга.

Подойдет ли такое решение?

CREATE TABLE account_roles (
    role_id TINYINT UNSIGNED NOT NULL UNIQUE AUTO_INCREMENT PRIMARY KEY,
    role_name ENUM('administrator', 'company', 'guest')
);

CREATE TABLE account_statuses (
    status_id TINYINT UNSIGNED NOT NULL UNIQUE AUTO_INCREMENT PRIMARY KEY,
    status_name ENUM('activated', 'not_activated', 'banned')
);

CREATE TABLE accounts (
    account_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    account_login VARCHAR(50) NOT NULL UNIQUE,
    account_email VARCHAR(70) NOT NULL UNIQUE,
    account_password_hash VARCHAR(255) NOT NULL,
    role_id TINYINT UNSIGNED NOT NULL,
    status_id TINYINT UNSIGNED NOT NULL,
    FOREIGN KEY (role_id) REFERENCES account_roles(role_id),
    FOREIGN KEY (status_id) REFERENCES account_statuses(status_id)
);

CREATE TABLE companies (
    company_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    company_name VARCHAR(150) NOT NULL UNIQUE,
    company_address VARCHAR(200) NOT NULL,
    company_unp TINYINT UNSIGNED NOT NULL UNIQUE,
    account_id BIGINT UNSIGNED NOT NULL UNIQUE,
    FOREIGN KEY (account_id) REFERENCES accounts (account_id)
);

Какие должны быть таблицы тогда в БД?

На самом деле какие угодно. Вариант с одной таблицей имеет свои плюсы.

Есть какой-то сакральный смысл в таблицах для статусов и ролей?

У одной компании может быть n сотрудников по идее. А у сотрудника n ролей, если эти роли не ограничиваются 'admin','company','guest'
Короче без предметной области это всё так себе советы.

В предложеном варианте как минимум неточность в

    company_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
);

Тут AUTO_INCREMENT лишнее. Генерация ид должна быть в одном месте.

А так, чтобы ответить на вопрос нужно или нет разделять аккаунты на части в зависимости от категории клиента ответь на вопросы:

• нужны ли отдельные выборки или отдельные джойны по отдельным категориям?
• нужны ли выборки или джойны вне зависимости от категории?
• возможно ли ссылки только на физиков или только на юриков, то есть ссылочная целостность по отдельным категориям?
• возможны ли ссылки на клиентов вне зависимости от их категории?

В зависимости от ответов будет выбор одного из вариантов:

• хранить всех клиентов в одной таблице
• хранить клиентов в разных таблицах (некоторые поля будут совпадать),
• хранить общую информацию в отдельной таблице, а детализированую по каждой категории клиента в дригих таблицах

Последний вариант наиболее универсальный, так как позволяет поддерживать ссылочную целостность как общую , так и по отдельным категориям. И выборки или джойны отдельных категорий будут более эффективны в некоторых случаях.

Есть какой-то сакральный смысл в таблицах для статусов и ролей?

Разделение логики по принципам ООП.

Тут AUTO_INCREMENT лишнее. Генерация ид должна быть в одном месте.

Так это же генерация id компаний, всё верно же.

За развернутый ответ отдельная благодарность.

Так это же генерация id компаний, всё верно же.

Точно, перепутал с account_id

А я бы начал с тех объектов которые будут использоваться в коде при работе с этими лицами и уже потом думал бы о том как это должно быть в базе для эффективности запросов.

Может в его случае будет удобнеее вообще сделать полиморфную связь от аккаунтов к юр и физ лицам. Если например внезапно (как всегда и бывает) окажется что для юр лиц на самом деле нужно несколько аккаунтов с разным статусом, а вообще могут быть еще и гос органы или хрен знает кто еще кто выбивается из категории физ/юр.

UPD: А ну в принципе у тебя там и есть полиморфная связь но размазанная по таблицам и какая то кривая…

Разделение логики по принципам ООП.

Какой именно ты там принцип увидел?)

Какой именно ты там принцип увидел?)

Каждый объект - отдельная сущность в Java)

Короче, там можно было бы увидеть Single Responsibility но в таком случае account_id в таблице companies лишний) Таска на изменение системы аккаунтов затронет реализацию компаний, SRP нарушается.)

но в таком случае account_id в таблице companies лишний

А как тогда в таблицу companies привязать пользователя?)

Таска на изменение системы аккаунтов

Это какую команду вы имеете ввиду и что понимаете под понятием «система аккаунтов»?)

А как тогда в таблицу companies привязать пользователя?)

как угодно, можно через связывающую таблицу, можно в самих аккаунтах указывать связь в формате table_name+PK

Это какую команду вы имеете ввиду и что понимаете под понятием «система аккаунтов»?)

таблица аккаунтов вероятно существует не сама по себе, есть какая нибудь моделька если там MVC какой нибудь. Есть объекты которые работают с этой моделькой. И вот когда менеджеры попросят изменить все это под новые фичи эти изменения не должны затрагивать список компаний, новостную ленту или воронку продаж… Single Responsibility именно про это.

У юридического лица нет таких атрибутов как фамилия и email. Там юридический адрес (регион, город, улица, дом, офис или вообще квартира), ИНН, ОГРН, ОКПО, название банка, корр. счет, генеральный директор, учредители, которые могут быть как физическими лицами так и юридическими… Ты какую-то хрень придумываешь

У тебя должна быть таблицs users (id, username, email, password, …) и companies (id, name, …) у компании есть форма собственности (ИП, ООО, АО и тп) + третья таблица user_companies (id, user_id, company_id, название должности). Один человек может быть формлен как самозанятый (упрощенное налогооблажение), ИП и быть гендиром, учредителем в куче компаний. У тебя тимлид 23-летний чмошник на самокате?

Дополнительные атрибуты компании, так как у разных форм собственности разное их количество, просто храни в виде сериализованной структуры (json)