Здравствуйте, MasterZiv, Вы писали:

MZ>1kulibin пишет:

>> сейчас вот вспомнил — это однако для упрощения работы с таблицей на
>> клиентском приложении — при конкурентном доступе. Т.е. такая ситуация:
>> один чел на клиенте получил запись с двойным вашим примари кеем (1,1)
>> допустим. пока он тупил другой чел отредактировал его на (2,2). потом
>> первый чел говорит серверу, мол update some_table set f1=3, f2=3 where
>> *f1=1 and f2=1*. а потом получается что? получается что клиентское

MZ>Е-р-у-н-д-а.
MZ>Это -- проблема того, что ты разрешаешь модифицировать
MZ>первичный ключ. Она всегда будет, независимо от того, составной
MZ>он или нет.
обоими руками за — истину глаголиш
>> этой id — НИКОГДА не редактируемый пользователем — тогда у нас всё будет

MZ>Я не говорил, что PK должен быть модифицируемым нигде, так что — доводы
MZ>мимо. PK должен быть всегда немодифицируемым, но это независит от
MZ>того, составной он или нет — это несвязанные вещи.
есть доля правды в словах "Я не говорил, что PK должен быть модифицируемым нигде" — однако полностью правильными они были бы если добавить к ним "В ЯВНОЙ ФОРМЕ" . Т.е. если бы ты написал "Я не говорил, что PK должен быть модифицируемым нигде В ЯВНОЙ ФОРМЕ" — было бы правильнее. Однако фраза "так что — доводы мимо" стала бы не правильной . ну это шутка юмора. Теперь серьёзно: чтобы PK был немодифицируем, он не должен видимо нести никакой смысловой нагрузки — так? т.е. его функции должны заканчиваться токо на том, что он PK — т.е. просто уникально идентифицирует строку таблицы — тогда действительно никогда не возникнет необходимости его править. а в нашем примере — честно скажу — не уверен — но возможно править составной этот PK когдато таки может понадобиться. Хотя как — если из бизнес-логики следует, что эти отношения многие-ко-многим один раз только задаются — и никогда не изменяются — то можно и составной пк делать. но лично у меня есть в этом большие сомнения — хотя автору топика конечно виднее.
вобщем я пока остаюсь при своём мнении что нужно продолжать без разбору везде лепить пк в виде ид автоинкрементного (или кому что больше нравится — мне так нравится) — в т.ч. и в таблицы отношений многие-ко-многим. теперь я вспомнил зачем я это делаю

1kulibin пишет:

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

> . ну это шутка юмора. Теперь серьёзно: чтобы PK был немодифицируем, он
> не должен видимо нести никакой смысловой нагрузки — так? т.е. его

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

> возникнет необходимости его править. а в нашем примере — честно скажу —
> не уверен — но возможно править составной этот PK когдато таки может
> понадобиться.

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

> вобщем я пока остаюсь при своём мнении что нужно продолжать без разбору
> везде лепить пк в виде ид автоинкрементного (или кому что больше
> нравится — мне так нравится) — в т.ч. и в таблицы отношений

Ну ... что уж тут сказать ... ничего и не скажешь, оставайся.

Здравствуйте, 1kulibin, Вы писали:

1>Здравствуйте, MasterZiv, Вы писали:

MZ>>1kulibin пишет:

1>есть доля правды в словах "Я не говорил, что PK должен быть модифицируемым нигде" — однако полностью правильными они были бы если добавить к ним "В ЯВНОЙ ФОРМЕ" . Т.е. если бы ты написал "Я не говорил, что PK должен быть модифицируемым нигде В ЯВНОЙ ФОРМЕ" — было бы правильнее. Однако фраза "так что — доводы мимо" стала бы не правильной . ну это шутка юмора. Теперь серьёзно: чтобы PK был немодифицируем, он не должен видимо нести никакой смысловой нагрузки — так? т.е. его функции должны заканчиваться токо на том, что он PK — т.е. просто уникально идентифицирует строку таблицы — тогда действительно никогда не возникнет необходимости его править. а в нашем примере — честно скажу — не уверен — но возможно править составной этот PK когдато таки может понадобиться. Хотя как — если из бизнес-логики следует, что эти отношения многие-ко-многим один раз только задаются — и никогда не изменяются — то можно и составной пк делать. но лично у меня есть в этом большие сомнения — хотя автору топика конечно виднее.
1>вобщем я пока остаюсь при своём мнении что нужно продолжать без разбору везде лепить пк в виде ид автоинкрементного (или кому что больше нравится — мне так нравится) — в т.ч. и в таблицы отношений многие-ко-многим. теперь я вспомнил зачем я это делаю

А могут ли существовать две "разных" связи между одними и теми же записями?
А имеет ли смысл идентифицировать отдельную связь и рассматривать такое явление как "раньше ЭТА связь была между такими двумя записями, а потом она ПЕРЕШЛА на другие две записи"?

Я думаю, в 99% случаев — нет.

Здравствуйте, MasterZiv, Вы писали:

MZ>ViktorZ пишет:
>>
>> А какой индекс ещё понадобится?

MZ>Надо два, (user,group) и (group,user).

Если оба FK суррогатные, то сомневаюсь, что будут запросы с range.
То есть, нужно два индекса:
(user, group) и (group).

Здравствуйте, MasterZiv, Вы писали:

MZ>Аноним 570 пишет:

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

MZ>Ну так ничего страшного не будет и в первом случае. Будет просто
MZ>таблица (сущность), PK которой состоит из 2-х полей.

MZ>Знаешь еще какой довод бывает за 2-ой способ ?
MZ>Некоторые люди просто не умеют работать (писать запросы)
MZ>с таблицами с составными ключами, и, по низкой своей квалификации,
MZ>лепят везде поле ID с IDENTITY без разбору, надо это или нет.

>> случае реализации именно такой одной связи, отдельное поле для
>> первичного ключа действительно необходимо.

MZ>Неправда, оно НЕ НЕОБХОДИМО. Можно делать и самостоятельную
MZ>сущность с PK из нескольких полей. В чем проблема-то ?
Если связь является самостоятельной сущностью, то суррогатный PK — жесткая необходимость.
Это на самом деле вопрос сугубо семантический.

Предположим, что мы выполняем ассоциацию Работников и Проектов.
Пока нам всего лишь важен сам факт участия работника в проекте, можно обходиться композитным PK на основе ссылок: один работник всё равно не может участвовать в проекте дважды.
Но у связи работника с проектом может быть и семантика отдельной сущности: Работник работает в Проекте на основе Контракта. У контракта могут быть, к примеру, сумма оплаты, должность, и сроки действия.

Теперь возникает ситуация изменения условий контракта; в такой семантике корректнее говорить об изменении контракта №xxx, а не "того контракта, который по поводу Иванова в Northwind". Ну, например потому, что Иванов запросто может иметь два контракта в один проект — с разными должностями.