Помогите с заказчиками физ.лица - юр.лица , в одну таблицу

[den_on_dream]

Проектирую БД. Простую реляционную.
В ней должны быть заказчики.
Заказчики могут быть как физ.лица (Вера Павловна), так и юр.лица (ООО "Рогатый скот").
Хочется всех заказчиков поместить в одну таблицу. Для упрощение ссылок извне.
Но как тогда быть с разным набором полей? С именем я определился: поле Name - ФИО человека или название компании.
Но у физ.лица есть пол, дата рождения, паспорт и т.д.
У юр.лица всякие реквизиты. Получается простыня полей, плюс поле кто это (физ или юр).

Помогите, как в таких случаях обычно поступают? Или я неправильно делаю? Но если делать две разные таблицы, то придется заморачиваться с ссылками из других таблиц, например из таблицы Заказы...

[Павел Калугин]

den_on_dream а куда потом денешь "банки", "фонды" и прочие лица?
Нарисуй общую таблицу со всеми атрибутами и примени алгоритмы нормализации. Увидишь какая красота получится.
В идеале количество типов лиц +1таблица

Сообщение отредактировано: Павел Калугин - 01.03.15, 13:11

[den_on_dream]

Павел, а можно подробнее про нормализацию? Это одна таблица (как я и хотел) и как-то скрывать часть полей?

[den_on_dream]

сколько ни искал про нормализацию БД, находятся шесть нормальных форм NF1-NF6. Но как они вяжутся с моим вопросом, не могу понять.

[Павел Калугин]

Очень просто вяжутся. Все данные лиц в одной таблице это 1НФ
Преобразуйте хотя бы к 3НФ

Можно пойти другим путем, объектным
Есть объект "лицо" у которого наследники "физ.лицо" и "юр лицо"
Попробуйте нарисовать это в виде ER диаграммы.

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

[Akina]

Вариантов несколько.

Две таблицы - одна на физиков, вторая на юриков.
Три таблицы - общая часть, специфичная для физиков, специфичная для юриков.
Две таблицы - общая часть, специфичная в EAV-формате.
Одна таблица - открытая общая часть, сериализованная специфичная часть.

Остальные варианты - вариация перечисленных.

[Павел Калугин]

Цитата Akina @ 01.03.15, 20:23

специфичная в EAV-формате.

Это инновация какая-то?

[Akina]

Павел Калугин
Нет, никакой инновации

Общая часть

id	name	INN	other fields
1	ООО Рога и копыта	11111111111	........
1	Пупкимн Василий Парамонович	22222222222	........

Специфичная EAV-часть

id	name	value
1	КПП	123456789
1	факс	(495)123-45-67
2	паспорт	45 00 123456
2	наличие авто	нет

[Павел Калугин]

Akina О как. Такой способ давно знаю, но что он так мудрено называется не слышал...

[den_on_dream]

Цитата Павел Калугин @ 01.03.15, 19:16

Да, вопрос это лаба, задание к собеседованию или уже работа?

Уже работа
Хочется, чтоб получилось как можно проще, чтоб потом легче использовать.

Цитата Akina @ 01.03.15, 20:23

Вариантов несколько.

Спасибо за перечисление вариантов.

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

[Akina]

Цитата den_on_dream @ 02.03.15, 17:52

буду думать, каким путем пойти

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

[Павел Калугин]

den_on_dream в принципе самый удобный для меня вариант этот :

Цитата Akina @ 01.03.15, 20:23

Три таблицы - общая часть, специфичная для физиков, специфичная для юриков.

Кстати именно на него пытался Вас натолкнуть предлагая провести нормализацию.
Преимущества
- легко масштабируется при появлении нового типа лиц (например отдельно Банки придется вести) просто добавляется в справочник типов лиц еще одна запись и еще одна таблица содержащая специфические для Банка атрибуты
- скорость доступа связь ID-ID в запросах по первичным ключам отрабатывает чуть медленнее чем моментально
- не нужно громоздких конструкций чтобы обратится к значению поля как при использовании EAV. Хотя полностью от этой технологии тоже не стоит отказываться. Очень удобно так хранить например всякие интеграционные коды.
- аккуратная и легко читаемая схема данных

[Akina]

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

select common.fieldset, coalesce(uric.fieldset, phys.fieldset)
from common left join uric left join phys

Достаточно сложно строить единый индекс по специфичной части без учёта, и невозможно - уникальный. А бывает надо - скажем, ИНН раньше был только у юриков, теперь у всех... или перетряхивать всю структуру - и все запросы.
Легкочитаемая схема данных становится хреновочитаемой, когда специфические части замыкаются на общую таблицу-справочник (скажем, адресный). Более того - чуть не досмотрел, и готова петля, можно программировать табуретку.
Да много чего...

[Павел Калугин]

Akina? Зачем такие сложности
Когда не важно физик или юрик то просто

select * from t_person

Цитата Akina @ 03.03.15, 11:16

А бывает надо - скажем, ИНН раньше был только у юриков, теперь у всех

Только у юриков он бил обязательнеым так и остался, а у физиков он не обязателен. И размерность разная. Посему увы это "специфическая для типа лица информация"
Ну и ПБЮЛ куда? Это еще не юрик но уже и не физик А еще точнее это физик с атрибутикой юрика.

Цитата Akina @ 03.03.15, 11:16

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

А зачем? Адрес регистрации и почтовый адрес есть у всех. Какие еще там типы адресов? B зачем это вязать со специфической частью? Особенно учитывая связь основной и специфической части ID-ID

Цитата Akina @ 03.03.15, 11:16

Достаточно сложно строить единый индекс по специфичной части без учёта, и невозможно - уникальный.

Совсем не понял. Давай всеж структуру смотреть.
Как-то так, для скорости
t_person(
id
type_id
short_name
full_name
)
t_person_jur(
id
jur_inn NOT NULL
OGRN
d_reg
)
t_person_phis(
f
I
o
phis_INN NULL
d_birth
)

О какого вида индексех речь?

[Akina]

Да мало ли какая будет операция, кою ускорит индекс. Вот хочу список клиентов, ИНН которых начинается на "123".