Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.219.189.247] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
Проектирую БД. Простую реляционную.
В ней должны быть заказчики. Заказчики могут быть как физ.лица (Вера Павловна), так и юр.лица (ООО "Рогатый скот"). Хочется всех заказчиков поместить в одну таблицу. Для упрощение ссылок извне. Но как тогда быть с разным набором полей? С именем я определился: поле Name - ФИО человека или название компании. Но у физ.лица есть пол, дата рождения, паспорт и т.д. У юр.лица всякие реквизиты. Получается простыня полей, плюс поле кто это (физ или юр). Помогите, как в таких случаях обычно поступают? Или я неправильно делаю? Но если делать две разные таблицы, то придется заморачиваться с ссылками из других таблиц, например из таблицы Заказы... |
Сообщ.
#2
,
|
|
|
den_on_dream а куда потом денешь "банки", "фонды" и прочие лица?
Нарисуй общую таблицу со всеми атрибутами и примени алгоритмы нормализации. Увидишь какая красота получится. В идеале количество типов лиц +1таблица |
Сообщ.
#3
,
|
|
|
Павел, а можно подробнее про нормализацию? Это одна таблица (как я и хотел) и как-то скрывать часть полей?
|
Сообщ.
#4
,
|
|
|
сколько ни искал про нормализацию БД, находятся шесть нормальных форм NF1-NF6. Но как они вяжутся с моим вопросом, не могу понять.
|
Сообщ.
#5
,
|
|
|
Очень просто вяжутся. Все данные лиц в одной таблице это 1НФ
Преобразуйте хотя бы к 3НФ Можно пойти другим путем, объектным Есть объект "лицо" у которого наследники "физ.лицо" и "юр лицо" Попробуйте нарисовать это в виде ER диаграммы. Да, вопрос это лаба, задание к собеседованию или уже работа? Просто в зависимости от того что это надо оформлять по разному |
Сообщ.
#6
,
|
|
|
Вариантов несколько.
Две таблицы - одна на физиков, вторая на юриков. Три таблицы - общая часть, специфичная для физиков, специфичная для юриков. Две таблицы - общая часть, специфичная в EAV-формате. Одна таблица - открытая общая часть, сериализованная специфичная часть. Остальные варианты - вариация перечисленных. |
Сообщ.
#7
,
|
|
|
Цитата Akina @ специфичная в EAV-формате. Это инновация какая-то? |
Сообщ.
#8
,
|
||||||||||||||||||||||||||||
|
Павел Калугин
Нет, никакой инновации Общая часть
Специфичная EAV-часть
|
Сообщ.
#9
,
|
|
|
Akina О как. Такой способ давно знаю, но что он так мудрено называется не слышал...
|
Сообщ.
#10
,
|
|
|
Цитата Павел Калугин @ Да, вопрос это лаба, задание к собеседованию или уже работа? Уже работа Хочется, чтоб получилось как можно проще, чтоб потом легче использовать. Цитата Akina @ Вариантов несколько. Спасибо за перечисление вариантов. В общем, спасибо всем ответившим. Информацию принял, буду думать, каким путем пойти. |
Сообщ.
#11
,
|
|
|
Цитата den_on_dream @ буду думать, каким путем пойти Выбор делайте, исходя из знания, как Вы будете работать с данными. Пополнять, удалять, изменять, выбирать... структура должна отвечать именно этому. |
Сообщ.
#12
,
|
|
|
den_on_dream в принципе самый удобный для меня вариант этот :
Цитата Akina @ Три таблицы - общая часть, специфичная для физиков, специфичная для юриков. Кстати именно на него пытался Вас натолкнуть предлагая провести нормализацию. Преимущества - легко масштабируется при появлении нового типа лиц (например отдельно Банки придется вести) просто добавляется в справочник типов лиц еще одна запись и еще одна таблица содержащая специфические для Банка атрибуты - скорость доступа связь ID-ID в запросах по первичным ключам отрабатывает чуть медленнее чем моментально - не нужно громоздких конструкций чтобы обратится к значению поля как при использовании EAV. Хотя полностью от этой технологии тоже не стоит отказываться. Очень удобно так хранить например всякие интеграционные коды. - аккуратная и легко читаемая схема данных |
Сообщ.
#13
,
|
|
|
Павел Калугин
Недостатков тоже хватает. Наиболее существенный - сложность обработки, когда неважно, физик это или юрик. Начинаешь строгать монстров типа select common.fieldset, coalesce(uric.fieldset, phys.fieldset) from common left join uric left join phys Достаточно сложно строить единый индекс по специфичной части без учёта, и невозможно - уникальный. А бывает надо - скажем, ИНН раньше был только у юриков, теперь у всех... или перетряхивать всю структуру - и все запросы. Легкочитаемая схема данных становится хреновочитаемой, когда специфические части замыкаются на общую таблицу-справочник (скажем, адресный). Более того - чуть не досмотрел, и готова петля, можно программировать табуретку. Да много чего... |
Сообщ.
#14
,
|
|
|
Akina? Зачем такие сложности
Когда не важно физик или юрик то просто select * from t_person Цитата Akina @ А бывает надо - скажем, ИНН раньше был только у юриков, теперь у всех Только у юриков он бил обязательнеым так и остался, а у физиков он не обязателен. И размерность разная. Посему увы это "специфическая для типа лица информация" Ну и ПБЮЛ куда? Это еще не юрик но уже и не физик А еще точнее это физик с атрибутикой юрика. Цитата Akina @ когда специфические части замыкаются на общую таблицу-справочник (скажем, адресный). А зачем? Адрес регистрации и почтовый адрес есть у всех. Какие еще там типы адресов? 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 ) О какого вида индексех речь? |
Сообщ.
#15
,
|
|
|
Да мало ли какая будет операция, кою ускорит индекс. Вот хочу список клиентов, ИНН которых начинается на "123".
|
Сообщ.
#16
,
|
|
|
ну вы тут сошлись в бое ))
|
Сообщ.
#17
,
|
|
|
den_on_dream
Да вряд ли... я уже говорил - оптимальная структура зависит в значительной, если не основной, части от того, какие операции выполняются над данными. Какова процентная раскладка по ISUD, какова статичность данных, какие типы запросов и по каким атрибутам связывания и отбора превалируют, есть ли система логической архивации... да просто тупо от объёма данных и характеристик сервера по отношению к объёму. Каждая схема хранения имеет свои плюсы и минусы, и в определённых условиях плюсы могут быть решающими или незначительными, а минусы незначимыми или критичными. |
Сообщ.
#18
,
|
|
|
Цитата den_on_dream @ ну вы тут сошлись в бое )) Да какой бой, просто обсуждаем. Ибо подобные констрахции постоянно использовать приходится Те же договора по типам. Поди разберись какой тип договора расширением какого является. А если с этими типами еще и заморочится грамотно то там и процедуры обработки наследуются, и прочая красивость возможна. И вот думай как лучше, в какую сторону "оптимизировать" в сторону быстродействия или удобства разработки или или или... |
Сообщ.
#19
,
|
|
|
Цитата Павел Калугин @ в сторону быстродействия или удобства разработки или или или... Золотую середину |
Сообщ.
#20
,
|
|
|
Bas
Золотая середина - это в том редком случае, когда разработчик не только сам поддерживает продукт, но ещё и участвует в производственном процессе, который этот продукт обслуживает. Иначе как правило идёт перекос в сторону удобства именно разработки - себя любить надо, а пипл схавает. |
Сообщ.
#21
,
|
|
|
Akina, ага, а еще этот разработчик должен с ростом системы стать архитектором и большой дубиной бить по рукам "новаторам".Но на практике ему этой дубиной махать не надо, потому он уходит проектировать следующую систему в другом месте. А новые разработчики перекашивают ядро то в одну то в другую сторону. И получается медленно шевелящаяся система крайне неудобная в разработке.
Сорри за флуд |