Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли делать отдельное поле для PK? / 25 сообщений из 96, страница 1 из 4
  1  все
18.02.2018, 01:14
    #39603587
Юзер 01
Юзер 01
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Здравствуйте.

При проектировании схемы базы использую суррогатный ключ (поле типа Int64).

Вопрос.
В случае, когда табличка лишь реализует связь типа "много::много", стоит ли для такой таблички создавать отдельное поле для PK, или обойтись парой полей, используемых для FK к связываемым табличкам?

Например, таблички:

USR - пользователи.
USR_GROUP - группы пользователей.

Табличка USR_IN_GROUP реализует связь многие-ко-многим, т.е., пользователь может принадлежать к нескольким группам.
Поля этой таблички- "USR_ID" и "USR_GROUP_ID" используются для FK к табличкам USR и USR_GROUP соответственно.
Вопрос: если ли смысл для добавления отдельного ID для таблички USR_IN_GROUP? Или просто наложить на пару полей USR_ID и USR_GROUP_ID ограничение первичного ключа?

Спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 02:50
    #39603598
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Юзер 01В случае, когда табличка лишь реализует связь типа "много::много", стоит ли для такой таблички создавать отдельное поле для PK, или обойтись парой полей, используемых для FK к связываемым табличкам?

Нет конечно, не нужно этого делать. Нужен один единственный ключ, состоящий из двух полей — связей.


Юзер 01Или просто наложить на пару полей USR_ID и USR_GROUP_ID ограничение первичного ключа?

Да. Именно так.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 05:24
    #39603605
Ennor Tiegael
Ennor Tiegael
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Юзер 01,

Если это чистая М:М связка, то нет конечно, не стоит - вы никогда не будете им пользоваться, скорее всего.

Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 10:58
    #39603620
Arm79
Arm79
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Ennor TiegaelЮзер 01,

Если это чистая М:М связка, то нет конечно, не стоит - вы никогда не будете им пользоваться, скорее всего.

Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля.
+1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 14:33
    #39603674
ViPRos
ViPRos
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Ennor TiegaelЮзер 01,

Если это чистая М:М связка, то нет конечно, не стоит - вы никогда не будете им пользоваться, скорее всего.

Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля.

"что если под этой таблицей развесистый кусок" - а это всегда так, если это не курсовая
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 14:44
    #39603676
Юзер 01
Юзер 01
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Ennor Tiegael...Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля.

С одной стороны - накладные издержки на введение отдельного поля для PK минимальны.
С другой стороны - следует ли при проектировании учитывать то, что в данный момент не требуется?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 22:20
    #39603819
Шавлюк Евгений
Шавлюк Евгений
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
У меня репликация построена на условии, что все таблицы имеют одно поле-PK , так что у меня у всех таблиц есть
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.02.2018, 22:29
    #39603825
LSV
LSV
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Бывают случаи когда удобно оперировать один полем. Например в проекте ведутся ссылки на документы/справочники и т.д. Обычно это одно целочисленное поле, на кот. удобно ссылаться.
И по сабжу может понадобиться иметь простую ссылку на запись в таблице (н-р для унифицированного поиска или прочих ссылок). В случае с составным ключом это неудобно или даже невозможно.
Если таблица среднебольшая то никаких накл. расходов на доп. поле нет.

по сабжу: Оба варианта имеют право на жизнь.
2 Ennor Tiegael: +500
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 02:29
    #39603871
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
ViPRos"что если под этой таблицей развесистый кусок" - а это всегда так, если это не курсовая

Параметризованная связь М:М? Это уже не совсем связь, потому что таким образом можно абсолютно 100% любую таблицу, имеющую 2 и больше foreign key рассматривать, как «развесистый кусок». Основная проблема разработчиков, это уход от терминологии, навешивание и подмена своего смысла, а потом все страдают.

На примере у ТС именно М:М. Ну добавь туда ещё дату и автора создания, ещё номер ревизии и ещё 50 технических полей, чтобы это не выглядело как курсовая. Что изменится?

Создание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего? Потому что кто-то там не может репликацию настроить? :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 02:47
    #39603872
bideveloper
bideveloper
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
hVosttНа примере у ТС именно М:М.
Да, тут отдельное поле для PK не нужно.
А вот если бы это были строки заказа )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 05:25
    #39603881
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
bideveloperДа, тут отдельное поле для PK не нужно.
А вот если бы это были строки заказа )

Дык это уже тогда и не М:М :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 07:40
    #39603899
skyANA
skyANA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Юзер 01Ennor Tiegael...Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля.

С одной стороны - накладные издержки на введение отдельного поля для PK минимальны.
С другой стороны - следует ли при проектировании учитывать то, что в данный момент не требуется?
При проектировании следует учитывать бизнес-логику: как данные запрашиваются, как изменяются.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 10:25
    #39603984
LSV
LSV
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Создание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего?Тебе, что жалко, бро ? :) Это мизерные накладные расходы. Никто и не заметит.
Если с т.з. разработки это поле действительно удобно/полезно, то его следует сделать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 10:28
    #39603988
skyANA
skyANA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
LSVСоздание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего?Тебе, что жалко, бро ? :) Это мизерные накладные расходы. Никто и не заметит.
Если с т.з. разработки это поле действительно удобно/полезно, то его следует сделать.
Да, да, ещё и кластерный индекс на это поле залепить, а на другие обычный. Не жалко
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 10:42
    #39604001
LSV
LSV
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
skyANAДа, да, ещё и кластерный индекс на это поле залепить, а на другие обычный. Не жалко Если в этом поле автоинкремент, то кластерный это норм.

зы: и тебе жалко ? :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 10:56
    #39604017
накладные изде
накладные изде
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Юзер 01С одной стороны - накладные издержки на введение отдельного поля для PK минимальны.
С другой стороны - следует ли при проектировании учитывать то, что в данный момент не требуется?
Великолепное описание фактического состояния. Поскольку никаких показателей ни к одному, ни к другому варианту не имеется, ровно так и надо делать. Как? Да как хочешь. Хоть монетку подбрось. В конце эксперимента появится немножко опыта, который позволит в следующий раз без подсказок че-нить порешать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 11:31
    #39604038
Cane Cat Fisher
Cane Cat Fisher
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Если говорить о чистой реляционной алгебре, то для связи N:N по определению достаточно двух полей, а третье без надобности.

Другое дело, что мало какие реальные проекты имеют счастье жить в рамках чистой реляционной алгебры. И со временем, столкнувшись с практическими требованиями, многие приходят к мысли, что в каждой таблице PK должен быть одним полем, даже в таком простом случае. Некоторые причины тут уже назвали - репликация, протоколирование изменений, единообразная работа со ссылками, всякие сторонние инструменты, которые хотят PK как одно поле.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 11:56
    #39604054
LSV
LSV
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Cane Cat Fisher,
+500.

зы: применяю оба подхода, есличо.
Но если в таблице много полей, то предпочитаю добавлять автонумератор. Для удобства.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 15:07
    #39604261
ViPRos
ViPRos
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
hVostt,

мало плавал :)
лучше любую связь рассматривать как М:М и при нужде наложить ограничение для сужения
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 15:52
    #39604319
ultrasonic7
ultrasonic7
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Извините, почему для репликации так уж необходимо, чтобы первичный ключ был только на одном поле? Если репликация основана на инструкции MERGE, то какая разница, что там у неё в JOIN CONDITION: Field1 = Value1 или Field1 = Value1 AND Field2 = Value2 ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.02.2018, 16:40
    #39604367
Шавлюк Евгений
Шавлюк Евгений
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
ultrasonic7,

Для МОЕЙ репликации так надо.
У меня есть таблица "лог изменений" вида (id таблицы, id записи, тип изменения i/u/d), по этим данным формируется пакет изменений.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.02.2018, 09:40
    #39604574
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
ViPRoshVostt,

мало плавал :)
лучше любую связь рассматривать как М:М и при нужде наложить ограничение для сужения

Звучит отвратительно даже в теории. Так то, ограничения foreign key -- злющее зло. Индексы -- надо бросать на все поля вдоль и поперёк. Всегда можно наложить ограничение в запросе, так?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.02.2018, 10:08
    #39604594
skyANA
skyANA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
LSVskyANAДа, да, ещё и кластерный индекс на это поле залепить, а на другие обычный. Не жалко Если в этом поле автоинкремент, то кластерный это норм.

зы: и тебе жалко ? :)для USR_IN_GROUP да
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.02.2018, 11:10
    #39604654
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
Шавлюк Евгений,

собственный велосипед для репликации? ))
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.02.2018, 11:15
    #39604659
hVostt
hVostt
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стоит ли делать отдельное поле для PK?
bideveloperДа, тут отдельное поле для PK не нужно.
А вот если бы это были строки заказа )

Насчёт строк заказа, так-то FK на позицию заказа это чисто дополнительная справочная информация. Заказ должен заморозить позицию, так, чтобы после того, как позиции товаров как-то менялись, это не повлияло на заказ. Либо записи товаров должны быть неизменными, любое изменение должно приводить к созданию новой записи. В общем, тут дело такое. Многие путают, не думая о системе в целом и обо всех аспектах функционирования системы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли делать отдельное поле для PK? / 25 сообщений из 96, страница 1 из 4
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 268ms
Закрыть
start [/forum/topic.php?fid=32&mobile=1&tid=1540075]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 135ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 70ms
get tp. blocked users:
 2ms
others: 14ms
total:  268ms
x
x
Закрыть


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