Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MySQL > Отношение disjoint

Автор: kvick 1.4.2012, 21:51

Вечер добрый. Представим, что у нас есть модель данных и в ней есть сущность "Клиент", "Клиент" может быть или "Физ. лицом" или "Юр. лицом", но ни как ни тем и не тем одновременно, и ничем иным. Соответственно, и в самой БД есть три таблицы - "Клиент", "Юр. лицо", "Физ. лицо", последние две зависимы от первой и как внешний ключ содержат ссылку на "клиент_ид". Согласно описанию нашей ПрО, юр. и физ. лицо не могут одновременно содержать ссылку на одного клиента. Можно ли как-то это контролировать не прибегая к помощи триггеров?

Автор: skyboy 1.4.2012, 22:40

я бы завел в таблице клиентов еще ENUM "тип клиента". тогда сам запрос будет контроллировать "только один тип". для физлиц и юрлиц в отдельных таблицах разный набор полей или один и тот же? если разный — то тем более, надо хранить флаг в таблице клиентов, чтоб запрос был на WHERE clients.type = 'PE' вместо  Код WHERE  exists(select pe.client_id from private_entrepreneur as pe where pe.client_id = client_id) and  not exists(select c.client_id from corporation as c where c.client_id = clientds.id) что ужасно. а если набор полей одинаков — то зачем добавлять дополнительные таблицы?

Автор: kvick 2.4.2012, 07:41

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

Автор: Akina 2.4.2012, 07:50

Цитата(skyboy @  1.4.2012,  23:40 ) я бы завел в таблице клиентов еще ENUM "тип клиента". Ссылка на таблицу атрибутов конкретного подтипа сущности уже есть энумерация атрибута "подтип".

Автор: Zloxa 2.4.2012, 08:53

Цитата(kvick @  1.4.2012,  22:51 )  Можно ли как-то это контролировать не прибегая к помощи триггеров?  Код create table contractor (contractor integer not null                          ,contractor_type char(1) not null check (contractor_type in ('N','A')) ); create index contractor$cntr_cntrtyp$idx on contractor (contractor,contractor_type); alter table contractor add constraint contractor$pk primary key (contractor) using index contractor$cntr_cntrtyp$idx; alter table contractor add constraint contractor$cntr_cntrtyp$unc unique (contractor, contractor_type) using index contractor$cntr_cntrtyp$idx; create table artificial_person(     contractor integer primary key     ,contractor_type char(1) not null check (contractor_type = 'A')     ,constraint ap$contractor$fk foreign key (contractor,contractor_type) references contractor(contractor, contractor_type)     ... );    create table natural_person(     contractor integer primary key     ,contractor_type char(1) not null check (contractor_type = 'N')     ,constraint np$contractor$fk foreign key (contractor,contractor_type) references contractor(contractor, contractor_type)     ... );    Это DDL для оракла, уверен для маси можно что-то вроде замутить. Добавлено через 10 минут и 58 секунд Цитата(Akina @ 2.4.2012,  08:50) Цитата(skyboy @  1.4.2012,  23:40 ) я бы завел в таблице клиентов еще ENUM "тип клиента". Ссылка на таблицу атрибутов конкретного подтипа сущности уже есть энумерация атрибута "подтип". Так то оно так, но неоднозначность может возникнуть. Нужно ли в действительности городить вышеприведенный огород с констрейнтами, я еще посомневаюсь(хотя сам горожу весьма регулярно). А вот за типизацию клиентов на уровне мастер таблицы я, лично, двумя руками за.

Автор: Akina 2.4.2012, 09:19

Цитата(Zloxa @  2.4.2012,  09:53 ) Нужно ли в действительности городить вышеприведенный огород с констрейнтами, я еще посомневаюсь Я сторонник обратного подхода - объявления каждого типа (ЮрЛицо, ФизЛицо) самостоятельной сущностью, и формирование объединяющей надсущности Клиент. Да, при этом в каждую связную таблицу вместо одного поля падает два - но как много геморроев уходит!

Автор: Zloxa 2.4.2012, 09:34

Цитата(Akina @ 2.4.2012,  10:19) Цитата(Zloxa @  2.4.2012,  09:53 ) Нужно ли в действительности городить вышеприведенный огород с констрейнтами, я еще посомневаюсь Я сторонник обратного подхода - объявления каждого типа (ЮрЛицо, ФизЛицо) самостоятельной сущностью, и формирование объединяющей надсущности Клиент. Да, при этом в каждую связную таблицу вместо одного поля падает два - но как много геморроев уходит! Тоже, конечно вариант  Но, случается, сферический в вакууме контрагент может иметь еще какие-либо атрибуты, не зависящие от его типа... да еще и в отношении один ко многим. Например контактные лица, телефоны, адреса доставки. Придется либо дублировать структуру этих атрибутов, либо закладываться на дуализм. С плоским справочником таки куда удобнее. К слову, у меня еще есть, скажем, справочник товаров. Он типизируется сейчас восемью значениями, пять из восьми типов имеют различные расширенные атрибуты, если идти по твоему пути... в строках накладных восемь ссылок надо держать и следить чтобы лишь одна not null была?

Автор: Akina 2.4.2012, 09:46

Цитата(Zloxa @  2.4.2012,  10:34 ) контрагент может иметь еще какие-либо атрибуты, не зависящие от его типа... да еще и в отношении один ко многим. Например контактные лица, телефоны, адреса доставки. Придется либо дублировать структуру этих атрибутов, либо закладываться на дуализм. С плоским справочником таки куда удобнее. Эммм... не понял... Да, в описании сущности каждого контрагента, никуда не деться, поля атрибутов дублированы. Но таблица такого атрибута - едина. И что, что на часть из них ссылается одна таблица, а на остальные - другая? Цитата(Zloxa @  2.4.2012,  10:34 ) в строках накладных восемь ссылок надо держать и следить чтобы лишь одна not null была?  Почему восемь? два поля - тип товара и его идентификатор в конкретной таблице товаров этого типа, причём оба not null. А уже из конкретной таблицы куда ссылки поведут - это пусть соотв. вьюшки разбираются.

Автор: Zloxa 2.4.2012, 09:50

Цитата(Akina @  2.4.2012,  10:46 ) на часть из них ссылается одна таблица, а на остальные - другая? Цитата(Akina @  2.4.2012,  10:46 )  два поля - тип товара и его идентификатор в конкретной таблице товаров этого типа, причём оба not null.  Получается, мы отказываемся от механизма внешнего ключа для контроля целостности.

Автор: Akina 2.4.2012, 10:49

Zloxa, почему? мы просто допускаем существование "подвисших" записей на стороне "много"...

Автор: Zloxa 2.4.2012, 10:56

Цитата(Akina @  2.4.2012,  11:49 ) Zloxa, почему? Потому что мы не можем прокинуть fk по константе. Увы.  Или мася умеет? Цитата(Akina @  2.4.2012,  11:49 ) Zloxa, почему? мы просто допускаем существование "подвисших" записей на стороне "много"...  Это ведь и есть следствие отказа ))) Зачем, ради чего, мы жертвуем согласованностью данных? Если с адресами контрагента как бы и фиг с ним, но вот с "подвисшими" строками накладной - уже как-то неуютно.

Автор: Akina 2.4.2012, 11:46

Цитата(Zloxa @  2.4.2012,  11:56 ) Или мася умеет? не-а...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)