ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Внешний ключ на две таблицы (+)
19 сообщений из 44, страница 2 из 2
  2  все
Внешний ключ на две таблицы (+)
    #33341077
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
пообсуждаем?... )
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
create table customer (
	customer_id	int not null,
	customer_type char( 1 ) not null, check (customer_type in ('P','O')),
	-- Общие атрибуты клиентов
	-- ...
	constraint PK primary key (customer_id,customer_type)
)@


create table people (
	customer_id	int not null,
	customer_type char( 1 ) not null check (customer_type in ('P')),
	-- Дополнительные атрибуты физ лиц
	-- ...
	constraint FK foreign key (customer_id,customer_type)
		references customer (customer_id,customer_type)
			on delete restrict on update restrict,
	constraint PK primary key (customer_id,customer_type)
)@


create table organization (
	customer_id	int not null,
	customer_type char( 1 ) not null check (customer_type in ('O')),
	-- Дополнительные атрибуты юр лиц
	-- ...
	constraint FK foreign key (customer_id,customer_type)
		references customer (customer_id,customer_type)
			on delete restrict on update restrict,
	constraint PK primary key (customer_id,customer_type)
)@

-- Как пример:
create table Doc (
	-- Производитель
	org_id int,
	org_type char( 1 ),
	-- Потребитель
	fl_id int,
	fl_type char( 1 ),
	-- Прочие атрибуты
	-- ...
	constraint FK_PEOPLE foreign key (org_id,org_type) references people (customer_id, customer_type),
	constraint FK_ORG foreign key (fl_id,fl_type) references organization (customer_id, customer_type)
)@
...
Рейтинг: 0 / 0
24.10.2005, 17:58
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33341203
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
gardenmanпообсуждаем?...
Как-то бессмысленно обсуждать, не имея постановки задачи. Флейм получится.

Из общих соображений - меня несколько смущает то, что people и organization обязаны быть customer-ами, ну и то, что я назвал "пляска с целостностью" - по понятным причинам аж в таблицу документов залезло техническое поле org_type. Наконец, в данной схеме чрезвычайно неудобен путь от "документа" к "общим атрибутам клиентов".

Итого - во-первых, я бы скорее протянул foreign key в обратную сторону (от customer к people/organization). Во-вторых, в doc ссылался бы на customer_id. В-третьих, убрал бы поле типа.
...
Рейтинг: 0 / 0
24.10.2005, 18:54
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33341224
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
автор, в данной схеме чрезвычайно неудобен путь от "документа" к "общим атрибутам клиентов".
Как раз наоборот. Все очень-очень просто. За общими отрибутами не надо ходить в People или Org - можно напрямую приджойнить customer.
автор
Итого - во-первых, я бы скорее протянул foreign key в обратную сторону (от customer к people/organization). Во-вторых, в doc ссылался бы на customer_id. В-третьих, убрал бы поле типа.
Приведите пример пожалуйста. Для наглядности.
...
Рейтинг: 0 / 0
24.10.2005, 19:15
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342116
hardsign
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hardsign
Гость
softwarer
Из общих соображений - меня несколько смущает то, что people и organization обязаны быть customer-ами,

Можно несколько переформулировать определение кастомера: это любой субъект, с которым приходится иметь дело. Тогда не жалко валить туда и физиков, и юриков. Контрагентом субъект становится в тот момент, когда с ним заключается соответствующий договор. Тогда, чтобы определить контрагента, надо идти от договора, а не от справочника клиентов. Вполне жизнеспособный подход.

softwarer ну и то, что я назвал "пляска с целостностью" - по понятным причинам аж в таблицу документов залезло техническое поле org_type.

Тоже жизнеспособный подход -- составной первичный ключ, часть которого является внешним ключом. Он тоже может кому-то не нравиться (как мне, например, не нравятся физические FK :)), но, тем не менее, это работает и в OLTP иногда очень удобно.
...
Рейтинг: 0 / 0
25.10.2005, 12:05
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342390
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
2 gardenman

Структурно ключом все-таки должен быть customer_id
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
create table customer (
	customer_id	int not null,
	customer_type char( 1 ) not null, check (customer_type in ('P','O')),
	-- Общие атрибуты клиентов
	-- ...
              
               constraint PK primary key (customer_id)
               constraint PK unique (customer_id,customer_type)
)@

create table people (
	customer_id	int not null,
	customer_type char( 1 ) not null check (customer_type in ('P')),
	-- Дополнительные атрибуты физ лиц
	-- ...
	constraint FK foreign key (customer_id,customer_type)
		references customer (customer_id,customer_type)
			on delete restrict on update restrict,
	constraint PK primary key (customer_id)
)@
А далее кому важно, чтобы тип не менялся, ссылаются на unique, а кому не важно - на primary key.

Во-вторых в косметических целях поменял бы название customer на party (действующее лицо). Клиент - это скорее роль. У одного действующего лица ролей может быть много.
...
Рейтинг: 0 / 0
25.10.2005, 13:15
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342469
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
авторСтруктурно ключом все-таки должен быть customer_id

Сможете обосновать?
автор
customer на party

Я подумаю над этим. Однако привычка - знаете ли большое дело.

По мне так абсолютно никакой разницы первичный ключ составной или из одного поля. Для меня существенно другое - Если клиент существует, то для него обязательно должна быть запись в таблице Customer. И опять же Customer должен быть упомянут только один раз и должен иметь совершенно определенный тип.
Единственная проблема которую я тут вижу - можно удалить строку из People а в Customer она останется. Поэтому без триггеров такая схема до конца не работает.
...
Рейтинг: 0 / 0
25.10.2005, 13:35
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342477
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
hardsignМожно несколько переформулировать определение кастомера: это любой субъект, с которым приходится иметь дело.
"Субъект" - согласен, будет нормальная сущность. А вот кастомер - не нравится; захочется внести туда собственных сотрудников и выяснится, что приходится обозвать их кастомерами :)

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select
  c.*
from 
  Document d,
  People p,
  Organization o,
  Customer c
where
  d.people_id = p.people_id (+) and
  d.organization_id = o.organization_id (+) and
  c.customer_id = coalesce ( p.customer_id, o.customer_id )

Получается так, что наиболее нужная информация засунута максимально далеко.

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

Как неформальный признак - imho такой подход оправдан, когда не нужно вносить дополнительных технических полей, то есть когда поля составного ключа по своему смыслу должны присутствовать в каждой из таблиц.
...
Рейтинг: 0 / 0
25.10.2005, 13:37
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342498
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
автор"Субъект" - согласен, будет нормальная сущность. А вот кастомер - не нравится; захочется внести туда собственных сотрудников и выяснится, что приходится обозвать их кастомерами :)


А что, собственный сотрудник разве не может быть кастомером?
...
Рейтинг: 0 / 0
25.10.2005, 13:43
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342511
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
2 softwarer
Таблицу Doc я привел в пример лишь для того, чтобы показать как можно накрутить ссылочную целостность на такую схему.
Например, если потебуется хранить организацию и ее сотрудников и обеспечить связь между ними.
...
Рейтинг: 0 / 0
25.10.2005, 13:48
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342542
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
gardenmanА что, собственный сотрудник разве не может быть кастомером?
Может. Но совершенно не обязан им быть. Поэтому внешние ключи, например, кастомер -> физик и сотрудник -> физик вполне удобны, а вот notnull-овский физик -> кастомер - искусственен, не отражает реальности.
...
Рейтинг: 0 / 0
25.10.2005, 13:56
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342563
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
gardenman авторСтруктурно ключом все-таки должен быть customer_id

Сможете обосновать?

Общеэстетические соображения:
Party_idParty_type1'O'1'P'
вызывает вопрос так '1' у нас человек или организация? Ответ ясен O1 это одно а P1- другое, но все же....
во-вторых включение смыслового атрибута в суррогатный ключ в общем случае не лучшая практика.

Производительность, кодирование: короткие ключи безусловно лучше.
А главное, цель (контроль целостности Party - Organization xor Person) достигается и при коротком ключе, зачем усложнять.

Наконец, если имеется существующая база, то одно дело добавить UNIQUE, другое реорганизовать PK.
...
Рейтинг: 0 / 0
25.10.2005, 14:01
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342586
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRНаконец, если имеется существующая база, то одно дело добавить UNIQUE, другое реорганизовать PK.
Хм. Возможно тупой вопрос, но - а в чем разница?
...
Рейтинг: 0 / 0
25.10.2005, 14:07
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33342633
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
2 ModelR
взвесил, что вы написали. действительно:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
create table customer (
	customer_id	int not null,
	customer_type char( 1 ) not null, check (customer_type in ('P','O')),
	-- Общие атрибуты клиентов
	-- ...
              
               constraint PK primary key (customer_id),
               constraint PK2 unique (customer_id,customer_type)
)@

create table people (
	customer_id	int not null,
	customer_type char( 1 ) not null check (customer_type in ('P')),
	-- Дополнительные атрибуты физ. лиц
	-- ...
	constraint FK foreign key (customer_id,customer_type)
		references customer (customer_id,customer_type)
			on delete restrict on update restrict,
	constraint PK primary key (customer_id)
)@



create table organization (
	customer_id	int not null,
	customer_type char( 1 ) not null check (customer_type in ('O')),
	-- Дополнительные атрибуты юр. лиц
	-- ...
	constraint FK foreign key (customer_id,customer_type)
		references customer (customer_id,customer_type)
			on delete restrict on update restrict,
	constraint PK primary key (customer_id)
)@
выглядит приятнее. Единственная проблема - на Customer появляется два ключа. Коррекция двух ключей - опять же - не самое лучшее. Для производительности (предположим таблица People будет содержать миллионы записей) следует создавать по два ключа и на Org и на People. Однако если удаления будут не часты в целом - устроит наверное многих. Можно сказать даже почти всех.
Я б на такую схему вообще поставил - "рекомендовано к использованию"
...
Рейтинг: 0 / 0
25.10.2005, 14:16
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33343009
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarer ModelRНаконец, если имеется существующая база, то одно дело добавить UNIQUE, другое реорганизовать PK.
Хм. Возможно тупой вопрос, но - а в чем разница?Нет тупых вопросов, есть тупые ответы. Надеюсь не этот. Имеется ввиду, что в действующей системе многие запросы, функции и другой код как правило составлены с учетом ПК. Переделываем ПК - переделывает джойны по ПК и еще массу кода.
...
Рейтинг: 0 / 0
25.10.2005, 16:05
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33343264
hardsign
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hardsign
Гость
[quot softwarer]В данном случае мне не нравится другое: для того, чтобы получить "общие атрибуты клиента", например категорию, нужно писать запрос типа

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select
  c.*
from 
  Document d,
  People p,
  Organization o,
  Customer c
where
  d.people_id = p.people_id (+) and
  d.organization_id = o.organization_id (+) and
  c.customer_id = coalesce ( p.customer_id, o.customer_id )

М-да, видать я недостаточно внимательно читал исходное сообщение. Конечно, маразм. Мне казалось, что тот факт, что ключ "субъекта" является уникальным (т.е. грубо говоря, и для физиков и для юриков берётся из одной последовательности), очевиден для всех и обсуждению не подлежит. А если взять из договора subject_id, то он будет ключом в subject, а также в одной из таблиц "физик" и "юрик"...
...
Рейтинг: 0 / 0
25.10.2005, 17:16
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33345618
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRИмеется ввиду, что в действующей системе многие запросы, функции и другой код как правило составлены с учетом ПК. Переделываем ПК - переделывает джойны по ПК и еще массу кода.
Cовершенно не обязательно. Если "старый ПК перестает быть уникальным" - тогда да, геморрой. Если же идет именно реорганизация, типа "старый ПК сделали просто уникальным, а ПК объявили что-то еще" - проблемы будут только у изрядно кривых приложений.
...
Рейтинг: 0 / 0
26.10.2005, 16:37
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33345639
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
hardsignМне казалось, что тот факт, что ключ "субъекта" является уникальным (т.е. грубо говоря, и для физиков и для юриков берётся из одной последовательности), очевиден для всех и обсуждению не подлежит. А если взять из договора subject_id, то он будет ключом в subject, а также в одной из таблиц "физик" и "юрик"...
Виноват, не подумал об этом. Похоже, просто сказалась привычка к другому типу структур.
...
Рейтинг: 0 / 0
26.10.2005, 16:44
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33345802
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarerЕсли "старый ПК перестает быть уникальным" - тогда да, геморрой. Если же идет именно реорганизация, типа "старый ПК сделали просто уникальным, а ПК объявили что-то еще" - проблемы будут только у изрядно кривых приложений.Согласен, смысл моего поста как раз в этом и был - сохранить уникальность как она есть. Но я под "реорганизацией" понимал именно то, что будет разрешено
Party_id; Party_type 1; 'O' 1; 'P'
"старый ПК (K1) сделали просто уникальным, а ПК объявили что-то еще (K2)" - мне не пришло в голову, я бы просто создал новый UNIQUE K2. Для чего может потребоваться перестановка ПК = K2 , UNIQUE = K1 ?
...
Рейтинг: 0 / 0
26.10.2005, 17:28
| Ответить | Цитировать | Написать  
Внешний ключ на две таблицы (+)
    #33346096
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelR Для чего может потребоваться перестановка ПК = K2 , UNIQUE = K1 ?
В оракле - для переупорядочивания index-organized table. Может и еще что-то можно придумать, но этого имхо достаточно.
...
Рейтинг: 0 / 0
26.10.2005, 19:05
| Ответить | Цитировать | Написать  
19 сообщений из 44, страница 2 из 2
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Внешний ключ на две таблицы (+)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]