ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Стоит ли делать отдельное поле для PK?
25 сообщений из 96, страница 1 из 4
  1  все
Стоит ли делать отдельное поле для PK?
    #39603587
Юзер 01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Юзер 01
Гость
Здравствуйте.

При проектировании схемы базы использую суррогатный ключ (поле типа 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, 01:14
| Ответить | Цитировать | Написать  
Стоит ли делать отдельное поле для PK?
    #39603598
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Юзер 01В случае, когда табличка лишь реализует связь типа "много::много", стоит ли для такой таблички создавать отдельное поле для PK, или обойтись парой полей, используемых для FK к связываемым табличкам?

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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