Составные ПК vs чистые суррогаты.

← →
ANB © (2006-10-02 11:07) [0]

Время от времени поднимается вопрос о естественных ID и составных ПК.
ИМХО :
Мой опыт показал, что в ЛЮБУЮ таблицу нужно не поленится и добавить поле для суррогатного ключа и его же сделать первичным ключом. И все связки делать именно по этим полям. Иначе грабли в какой то момент неминуемы.

← →
jack128 © (2006-10-02 11:09) [1]

в таблицу связи многие ко многим - тоже?

← →
ANB © (2006-10-02 11:12) [2]

> в таблицу связи многие ко многим - тоже?

Да. обязательно. особенно, если СУБД не поддерживает каскадное обновление ключей (оракл).

На эту граблю я уже наступал.

← →
Sergey13 © (2006-10-02 11:20) [3]

> [0] ANB © (02.10.06 11:07)

> Время от времени поднимается вопрос о естественных ID и
> составных ПК.

У тебя появились новые данные по этому вопросу? 8-)

← →
ораклоид (2006-10-02 11:21) [4]

похоже, что к этому мнению рано или поздно все приходят. :-)

← →
ораклоид (2006-10-02 11:21) [5]

похоже, что к этому мнению рано или поздно все приходят. :-)

← →
Johnmen © (2006-10-02 11:30) [6]

> Время от времени поднимается вопрос о естественных ID и
> составных ПК.

И не надоело пинать этот вопрос? Сколько можно???

← →
kaif © (2006-10-02 11:35) [7]

Не согласен.
Хотелось бы услышать доводы кроме "мой личный опыт".
Тем более что в ER-диаграммах для таблиц, имеющих первичный составной ключ, состоящий из одних внешних ключей, имеется специальное обозначение.
Мой опыт работы с IB говорит о том, что такое требование (всегда иметь еще первичный суррогат) для некоторых таблиц совершенно излишне.

← →
Курдль © (2006-10-02 11:35) [8]

> ораклоид (02.10.06 11:21) [4]
> похоже, что к этому мнению рано или поздно все приходят.
> :-)

К какому еще мнению?
Если у меня, согласно модели предметной области, сущность ПОКУПКА является ассоциацией между сущностями ТОВАР и ПОКУПАТЕЛЬ, то в соответствующей таблице был, есть и будет только один составной первичный ключ из идентификаторов таблиц ТОВАР и ПОКУПАТЕЛЬ.
Естественнее этого ничего быть не может! Любые другие "идентификаторы", "суррогатные ключи" и т.п. - прямой путь к нарушению целостности данных!

← →
Думкин © (2006-10-02 11:39) [9]

> Johnmen © (02.10.06 11:30) [6]

Ну да.
http://podgoretsky.com/ftp/Docs/Delphi/Tenser/10/index.html
Естественные ключи против искуственных ключей Автор: Анатолий Тенцер, статья 6-20 июля 1999 года, версия 1.1.

← →
Sergey13 © (2006-10-02 11:40) [10]

> [8] Курдль © (02.10.06 11:35)

Как нарушится целостность БД, если я, сделав ТОВАР + ПОКУПАТЕЛЬ уникальным ключом, введу суррогатный ПК, просто не желая всегда и всюду писать два поля связи вместо одного?

← →
Курдль © (2006-10-02 11:48) [11]

> Sergey13 © (02.10.06 11:40) [10]
> > [8] Курдль © (02.10.06 11:35)
>
> Как нарушится целостность БД, если я, сделав ТОВАР + ПОКУПАТЕЛЬ
> уникальным ключом, введу суррогатный ПК, просто не желая
> всегда и всюду писать два поля связи вместо одного?

Вам лениво это делать?

← →
jack128 © (2006-10-02 11:54) [12]

ANB © (02.10.06 11:12) [2]
если СУБД не поддерживает каскадное обновление ключей (оракл).
Мне думается, что изменение PK - есть абсолютное зло. А раз нету изменнения PK, то и каскад на обновление не нужен...

← →
Игорь Шевченко © (2006-10-02 11:58) [13]

jack128 © (02.10.06 11:54) [12]

> Мне думается, что изменение PK - есть абсолютное зло.

Абсолютного зла не существует.

← →
ораклоид (2006-10-02 12:14) [14]

> Вам лениво это делать?

Мне как-то в своё время довелось поддерживать систему, где в одной из таблиц был составной ПК из то ли из 5-ти, то ли из 6-ти полей. Честно скажу: объединить пару-тройку таблиц с этой в запросе - это было что-то.

← →
Lamer@fools.ua © (2006-10-02 12:21) [15]

>Составные ПК vs чистые суррогаты

Дежа вю :-)

← →
kaif © (2006-10-02 12:32) [16]

Есди не предполагается новых ссылок на "составную сущность", то, ИМХО, для некоторых (не-сильно-многомерных) сущностей оправдано использование составного первичного ключа.
Например, анализы чуваков по датам.
Имеются чуваки (ID,FIO)
Имеются анализы чуваков (CHUVAK_ID, ANALYSIS_DATE, VALUE)
Не вижу никакого смысла в суррогате в данном случае.

Но в большинстве случаев автор сабжа возможно и прав. Но не во всех.

← →
Игорь Шевченко © (2006-10-02 12:36) [17]

ANB © (02.10.06 11:07)

> Мой опыт показал, что в ЛЮБУЮ таблицу нужно не поленится
> и добавить поле для суррогатного ключа и его же сделать
> первичным ключом. И все связки делать именно по этим полям.
> Иначе грабли в какой то момент неминуемы.

ну давай я опять напомню про коды ISO для городов и стран, для которых суррогатные поля имеют не слишком большой смысл.

← →
xayam © (2006-10-02 13:00) [18]

> Игорь Шевченко © (02.10.06 12:36) [17]
> ...ну давай я опять напомню про коды ISO...

а запросто)) - http://xayam.by.ru/index.shtml?level1

← →
Игорь Шевченко © (2006-10-02 13:01) [19]

xayam © (02.10.06 13:00) [18]

Неужто живо ? Спасибо :)

← →
Sergey13 © (2006-10-02 13:03) [20]

> [11] Курдль © (02.10.06 11:48)
> Вам лениво это делать?
Да. Лень - двигатель прогресса! Прогресс я двигаю. 8-)

← →
xayam © (2006-10-02 13:06) [21]

> Игорь Шевченко © (02.10.06 13:01) [19]
> xayam © (02.10.06 13:00) [18]
> Неужто живо ?

а как же иначе

> ANB © (02.10.06 11:07)
> Мой опыт показал, что в ЛЮБУЮ таблицу нужно не поленится
> и добавить поле для суррогатного ключа и его же сделать
> первичным ключом. И все связки делать именно по этим полям.

да

← →
vuk © (2006-10-02 13:22) [22]

to Курдль © (02.10.06 11:35) [8]:
>Если у меня, согласно модели предметной области, сущность ПОКУПКА
>является ассоциацией между сущностями ТОВАР и ПОКУПАТЕЛЬ
Пример неудачный. В данном случае модель, скорее всего, неправильная.

← →
Курдль © (2006-10-02 13:57) [23]

> vuk © (02.10.06 13:22) [22]
> Пример неудачный. В данном случае модель, скорее всего, неправильная.

Модель вымышленная.
Если есть желание поспорить могу предложить такой вариант:

> >Если у меня, согласно модели предметной области, сущность АРТИКУЛ_В_КОРЗИНЕ
> >является ассоциацией между сущностями ТОВАР и ПОКУПАТЕЛЬ

← →
ANB © (2006-10-02 14:27) [24]

> Есди не предполагается новых ссылок на "составную сущность",
>

Вот и я так думал. А потом пришлось таки при развитии проекта на эту таблицу сослаться. Сделал сдуру двойную ссылку. Огреб проблемы при первой же попытке изменить привязку.

Оно, понимаешь, "не предполагается" завсегда может изменится на "не предполагалось, а надо".

← →
Внук © (2006-10-02 14:46) [25]

>>ANB © (02.10.06 11:07)
>>Мой опыт показал, что в ЛЮБУЮ таблицу нужно не поленится и добавить поле для суррогатного ключа и его же сделать первичным ключом. И все связки делать именно по этим полям. Иначе грабли в какой то момент неминуемы.
Поздравляю. Мой опыт это показал года два-три назад. Здесь был уже нехилый холивар на эту тему. Повторять не буду, просто зашел порадоваться на прозревшего.

← →
Курдль © (2006-10-02 14:46) [26]

> ANB © (02.10.06 14:27) [24]
> > Есди не предполагается новых ссылок на "составную сущность",
> Сделал сдуру двойную ссылку. Огреб проблемы при первой же попытке изменить привязку.

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

← →
ZeroDivide © (2006-10-02 14:59) [27]

> просто зашел порадоваться на прозревшего.

Аналогично. Всех прозревших поздравляю!!! С Днем Прозрения! С ДП, короче!

← →
evvcom © (2006-10-02 15:04) [28]

> [27] ZeroDivide © (02.10.06 14:59)

Предлагаешь в анкете еще одну дату завести? :)

evvcom © (02.10.06 15:04) [28]

> [27] ZeroDivide © (02.10.06 14:59)

Предлагаешь в анкете еще одну дату завести? :)

Эта дата иногда бывает сильно размыта, бывает даже на десятилетия. А иногда, у некоторых и не происходит совсем. Так, что тут... кхм.. опять дискриминация получается...

"А я... а я... а вот я... а я вам в морду дам!" ((с) Медвежонок и детского анекдота)

> Я думал, что "изменить привязку" - это перекинуть линию
> на концептуальной модели

Изменить привязку - в моем понимании перепривязать с помощью линковочной таблицы записи из связываемых. При этом поменяются один или оба ID в записи связи линковочной таблицы. И если эти поля являлись ПК и при этом на линковку есть ссылка из четвертой таблицы, то возникают проблемы.

> Поздравляю. Мой опыт это показал года два-три назад.

Мой - полтора. Просто не так давно наткнулся на утверждение вполне уважаемого участника форума, что можно делать составные ПК. Типа ервин же позволяет. Сие сбивает с толку новичков.

> [31] ANB © (02.10.06 15:36)

А что? Таки нельзя делать? Дума новый закон приняла? Ответственность уголовная или административная?
8-)

> [31] ANB © (02.10.06 15:36)
> утверждение вполне уважаемого участника форума, что можно
> делать составные ПК

Все зависит от задачи. Если все крутится на одном сервере, то я бы не стал так делать. Если же [18], то я бы составной, наверное, и использовал.

> [17] Игорь Шевченко © (02.10.06 12:36)
> ну давай я опять напомню про коды ISO для городов и стран,
> для которых суррогатные поля имеют не слишком большой смысл.

ИМХО, их, а также почтовые индексы и тому подобное можно приравнять к суррогатным ключам. Так что всё верно :-)

> ANB © (02.10.06 15:36) [31]
> Мой - полтора. Просто не так давно наткнулся на утверждение
> вполне уважаемого участника форума, что можно делать составные
> ПК. Типа ервин же позволяет. Сие сбивает с толку новичков.

Я не претендую на звание уважаемого участника форума, но могу привести достаточное количество утверждений уважаемых участников мирового IT, в которых говорится, что только так и надо делать, если база - реляционная, а наличие составного ПК максимально приближает модель БД к структуре моделируемой предметной области.
А то, что кому-то лениво писать запросы с несколькими полями, вместо одного, или тяжко перепрофилировать данные на "рабочей базе" в серьезных проектах в учет не берутся.

to Курдль © (02.10.06 13:57) [23]:
> >Если у меня, согласно модели предметной области, сущность
>>АРТИКУЛ_В_КОРЗИНЕ
> >является ассоциацией между сущностями ТОВАР и ПОКУПАТЕЛЬ
О! А здесь вообще отношение прямо в названии сущности: АРТИКУЛ в КОРЗИНЕ. Где там покупатель? :)

> vuk © (02.10.06 15:53) [36]
> О! А здесь вообще отношение прямо в названии сущности: АРТИКУЛ
> в КОРЗИНЕ. Где там покупатель? :)

Держит корзину :)

> Marser © (02.10.06 15:47) [34]
> ИМХО, их, а также почтовые
> индексы и тому подобное можно приравнять к суррогатным ключам.
> Так что всё верно :-)

Ну, не совсем так. Суррогатные ключи генерируются в самой системе и, например, при загрузке/выгрузке ничто не мешает сгенерировать другие их значения. Естественные ключи в отличие от суррогатных могут ещё помимо уникальности нести дополнительную мнемоническую информацию.

> [38] euru © (02.10.06 15:56)
>
> > Marser © (02.10.06 15:47) [34]
> > ИМХО, их, а также почтовые
> > индексы и тому подобное можно приравнять к суррогатным
> ключам.
> > Так что всё верно :-)
>
> Ну, не совсем так. Суррогатные ключи генерируются в самой
> системе и, например, при загрузке/выгрузке ничто не мешает
> сгенерировать другие их значения. Естественные ключи в отличие
> от суррогатных могут ещё помимо уникальности нести дополнительную
> мнемоническую информацию.

В таком ключе - согласен.

Составные ПК vs чистые суррогаты. Найти похожие ветки