Как лучше перепроектировать базу?

Question

[SteepZero]

В системе есть два вида клиентов: Client Individuals (физ. лица) и Client Legals (юр. лица)

Предыдущий разработчик реализовал деление на типы следующим образом:

Есть таблица clients, которая содержит информацию о привязанном к клиенту менеджере и прочие бизнес-данные

Есть таблица client_individuals, которая хранит в себе связть с записью из таблицы clients (client_id) и набор полей, характерный для физ. лиц (дата рождения, паспортные данные и т.д.)

Есть таблица client_legals, которая хранит в себе связть с записью из таблицы clients (client_id) и набор полей, характерный для юр. лиц (ОГРН, вебсайт, дата ренистрации и т.д.)

Такой вариант не кажется мне самым удобным

У меня есть идея такой структуры:
таблица clients - хранит created_at, updated_at, type (физ/юр)
таблица client_fields - хранит символьный код поля (code), название поля (name), описание поля (description)
таблица client_values - хранит значение поля (value), связь с символьным кодом поля (client_field_code) и клиентом (client_id)

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

Уверен, можно придумать менее пухлый и более удобный варинат

Answer 1

[imhuman]

Мне кажется существующий вариант вполне хорош и удобен. Чем он вам не угодил?

Answer 2

[kn0ckn0ck]

Предыдущий разработчик сделал все правильно, по классике.

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

Оставьте как было.

Answer 3

[sim3x]

3НФ
Все ок

Answer 4

[Andrey Tsvetkov]

таблица clients - id, created_at, updated_at, type
таблица client_fields - client_id, field_name, field_value

Но я так понимаю у вас примерно тоже самое, просто описание полей вынесено в отдельную таблицу. Вполне себе достойное решение

Answer 5

[d-stream]

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