Нарисуй общую таблицу со всеми атрибутами и примени алгоритмы нормализации. Увидишь какая красота получится.
В идеале количество типов лиц +1таблица
| Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > Базы данных: Общие вопросы > Помогите с заказчиками физ.лица - юр.лица |
| Автор: den_on_dream 01.03.15, 12:45 |
| Проектирую БД. Простую реляционную. В ней должны быть заказчики. Заказчики могут быть как физ.лица (Вера Павловна), так и юр.лица (ООО "Рогатый скот"). Хочется всех заказчиков поместить в одну таблицу. Для упрощение ссылок извне. Но как тогда быть с разным набором полей? С именем я определился: поле Name - ФИО человека или название компании. Но у физ.лица есть пол, дата рождения, паспорт и т.д. У юр.лица всякие реквизиты. Получается простыня полей, плюс поле кто это (физ или юр). Помогите, как в таких случаях обычно поступают? Или я неправильно делаю? Но если делать две разные таблицы, то придется заморачиваться с ссылками из других таблиц, например из таблицы Заказы... |
| Автор: Павел Калугин 01.03.15, 13:10 |
| den_on_dream а куда потом денешь "банки", "фонды" и прочие лица? Нарисуй общую таблицу со всеми атрибутами и примени алгоритмы нормализации. Увидишь какая красота получится. В идеале количество типов лиц +1таблица |
| Автор: den_on_dream 01.03.15, 13:56 |
| Павел, а можно подробнее про нормализацию? Это одна таблица (как я и хотел) и как-то скрывать часть полей? |
| Автор: den_on_dream 01.03.15, 15:15 |
| сколько ни искал про нормализацию БД, находятся шесть нормальных форм NF1-NF6. Но как они вяжутся с моим вопросом, не могу понять. |
| Автор: Павел Калугин 01.03.15, 19:16 |
| Очень просто вяжутся. Все данные лиц в одной таблице это 1НФ Преобразуйте хотя бы к 3НФ Можно пойти другим путем, объектным Есть объект "лицо" у которого наследники "физ.лицо" и "юр лицо" Попробуйте нарисовать это в виде ER диаграммы. Да, вопрос это лаба, задание к собеседованию или уже работа? Просто в зависимости от того что это надо оформлять по разному |
| Автор: Akina 01.03.15, 20:23 |
| Вариантов несколько. Две таблицы - одна на физиков, вторая на юриков. Три таблицы - общая часть, специфичная для физиков, специфичная для юриков. Две таблицы - общая часть, специфичная в EAV-формате. Одна таблица - открытая общая часть, сериализованная специфичная часть. Остальные варианты - вариация перечисленных. |
| Автор: Павел Калугин 02.03.15, 07:48 |
| Это инновация какая-то? |
| Автор: Akina 02.03.15, 08:54 | |||||||||||||||||||||||||||
| Павел Калугин Нет, никакой инновации Общая часть
Специфичная EAV-часть
|
| Автор: Павел Калугин 02.03.15, 09:39 |
| Akina О как. Такой способ давно знаю, но что он так мудрено называется не слышал... |
| Автор: den_on_dream 02.03.15, 17:52 |
| Уже работа  Хочется, чтоб получилось как можно проще, чтоб потом легче использовать. Спасибо за перечисление вариантов. В общем, спасибо всем ответившим. Информацию принял, буду думать, каким путем пойти. |
| Автор: Akina 03.03.15, 06:57 |
| Выбор делайте, исходя из знания, как Вы будете работать с данными. Пополнять, удалять, изменять, выбирать... структура должна отвечать именно этому. |
| Автор: Павел Калугин 03.03.15, 10:51 |
| den_on_dream в принципе самый удобный для меня вариант этот : Кстати именно на него пытался Вас натолкнуть предлагая провести нормализацию. Преимущества - легко масштабируется при появлении нового типа лиц (например отдельно Банки придется вести) просто добавляется в справочник типов лиц еще одна запись и еще одна таблица содержащая специфические для Банка атрибуты - скорость доступа связь ID-ID в запросах по первичным ключам отрабатывает чуть медленнее чем моментально - не нужно громоздких конструкций чтобы обратится к значению поля как при использовании EAV. Хотя полностью от этой технологии тоже не стоит отказываться. Очень удобно так хранить например всякие интеграционные коды. - аккуратная и легко читаемая схема данных |
| Автор: Akina 03.03.15, 11:16 |
| Павел Калугин Недостатков тоже хватает. Наиболее существенный - сложность обработки, когда неважно, физик это или юрик. Начинаешь строгать монстров типа <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> select common.fieldset, coalesce(uric.fieldset, phys.fieldset) from common left join uric left join phys Достаточно сложно строить единый индекс по специфичной части без учёта, и невозможно - уникальный. А бывает надо - скажем, ИНН раньше был только у юриков, теперь у всех... или перетряхивать всю структуру - и все запросы. Легкочитаемая схема данных становится хреновочитаемой, когда специфические части замыкаются на общую таблицу-справочник (скажем, адресный). Более того - чуть не досмотрел, и готова петля, можно программировать табуретку. Да много чего... |
| Автор: Павел Калугин 03.03.15, 13:29 |
| Akina? Зачем такие сложности Когда не важно физик или юрик то просто <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> select * from t_person Только у юриков он бил обязательнеым так и остался, а у физиков он не обязателен. И размерность разная. Посему увы это "специфическая для типа лица информация" Ну и ПБЮЛ куда? Это еще не юрик но уже и не физик А еще точнее это физик с атрибутикой юрика.А зачем? Адрес регистрации и почтовый адрес есть у всех. Какие еще там типы адресов? B зачем это вязать со специфической частью? Особенно учитывая связь основной и специфической части ID-ID Цитата Akina @ Достаточно сложно строить единый индекс по специфичной части без учёта, и невозможно - уникальный. Совсем не понял. Давай всеж структуру смотреть. Как-то так, для скорости 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 03.03.15, 13:42 |
| Да мало ли какая будет операция, кою ускорит индекс. Вот хочу список клиентов, ИНН которых начинается на "123". |
| Автор: den_on_dream 03.03.15, 19:24 |
| ну вы тут сошлись в бое )) |
| Автор: Akina 04.03.15, 05:59 |
| den_on_dream Да вряд ли... я уже говорил - оптимальная структура зависит в значительной, если не основной, части от того, какие операции выполняются над данными. Какова процентная раскладка по ISUD, какова статичность данных, какие типы запросов и по каким атрибутам связывания и отбора превалируют, есть ли система логической архивации... да просто тупо от объёма данных и характеристик сервера по отношению к объёму. Каждая схема хранения имеет свои плюсы и минусы, и в определённых условиях плюсы могут быть решающими или незначительными, а минусы незначимыми или критичными. |
| Автор: Павел Калугин 04.03.15, 13:42 |
| Да какой бой, просто обсуждаем. Ибо подобные констрахции постоянно использовать приходится Те же договора по типам. Поди разберись какой тип договора расширением какого является. А если с этими типами еще и заморочится грамотно то там и процедуры обработки наследуются, и прочая красивость возможна. И вот думай как лучше, в какую сторону "оптимизировать" в сторону быстродействия или удобства разработки или или или...  |
| Автор: Bas 04.03.15, 14:03 |
| Золотую середину  |
| Автор: Akina 04.03.15, 14:06 |
| Bas Золотая середина - это в том редком случае, когда разработчик не только сам поддерживает продукт, но ещё и участвует в производственном процессе, который этот продукт обслуживает. Иначе как правило идёт перекос в сторону удобства именно разработки - себя любить надо, а пипл схавает. |
| Автор: Павел Калугин 04.03.15, 14:58 |
| Akina, ага, а еще этот разработчик должен с ростом системы стать архитектором и большой дубиной бить по рукам "новаторам".Но на практике ему этой дубиной махать не надо, потому он уходит проектировать следующую систему в другом месте. А новые разработчики перекашивают ядро то в одну то в другую сторону. И получается медленно шевелящаяся система крайне неудобная в разработке. Сорри за флуд |