| 
 | 
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Здравствуйте.  При проектировании схемы базы использую суррогатный ключ (поле типа 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 ограничение первичного ключа? Спасибо. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 01:14 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Юзер 01В случае, когда табличка лишь реализует связь типа "много::много", стоит ли для такой таблички создавать отдельное поле для PK, или обойтись парой полей, используемых для FK к связываемым табличкам? Нет конечно, не нужно этого делать. Нужен один единственный ключ, состоящий из двух полей — связей. Юзер 01Или просто наложить на пару полей USR_ID и USR_GROUP_ID ограничение первичного ключа? Да. Именно так. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 02:50 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Юзер 01, Если это чистая М:М связка, то нет конечно, не стоит - вы никогда не будете им пользоваться, скорее всего. Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 05:24 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Ennor TiegaelЮзер 01, Если это чистая М:М связка, то нет конечно, не стоит - вы никогда не будете им пользоваться, скорее всего. Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля. +1 ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 10:58 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Ennor TiegaelЮзер 01, Если это чистая М:М связка, то нет конечно, не стоит - вы никогда не будете им пользоваться, скорее всего. Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля. "что если под этой таблицей развесистый кусок" - а это всегда так, если это не курсовая ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 14:33 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Ennor Tiegael...Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля. С одной стороны - накладные издержки на введение отдельного поля для PK минимальны. С другой стороны - следует ли при проектировании учитывать то, что в данный момент не требуется? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 14:44 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  У меня репликация построена на условии, что все таблицы имеют одно поле-PK , так что у меня у всех таблиц есть ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 22:20 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Бывают случаи когда удобно оперировать один полем. Например в проекте ведутся ссылки на документы/справочники и т.д. Обычно это одно целочисленное поле, на кот. удобно ссылаться. И по сабжу может понадобиться иметь простую ссылку на запись в таблице (н-р для унифицированного поиска или прочих ссылок). В случае с составным ключом это неудобно или даже невозможно. Если таблица среднебольшая то никаких накл. расходов на доп. поле нет. по сабжу: Оба варианта имеют право на жизнь. 2 Ennor Tiegael: +500 ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 18.02.2018, 22:29 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  ViPRos"что если под этой таблицей развесистый кусок" - а это всегда так, если это не курсовая Параметризованная связь М:М? Это уже не совсем связь, потому что таким образом можно абсолютно 100% любую таблицу, имеющую 2 и больше foreign key рассматривать, как «развесистый кусок». Основная проблема разработчиков, это уход от терминологии, навешивание и подмена своего смысла, а потом все страдают. На примере у ТС именно М:М. Ну добавь туда ещё дату и автора создания, ещё номер ревизии и ещё 50 технических полей, чтобы это не выглядело как курсовая. Что изменится? Создание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего? Потому что кто-то там не может репликацию настроить? :) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 02:29 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  hVosttНа примере у ТС именно М:М.  Да, тут отдельное поле для PK не нужно. А вот если бы это были строки заказа ) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 02:47 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  bideveloperДа, тут отдельное поле для PK не нужно. А вот если бы это были строки заказа ) Дык это уже тогда и не М:М :) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 05:25 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Юзер 01Ennor Tiegael...Другое дело, что если под этой таблицей развесистый кусок, и куча других таблиц ссылаются не нее, то тогда лучше сделать, чтобы не тянуть через FK два этих поля. С одной стороны - накладные издержки на введение отдельного поля для PK минимальны. С другой стороны - следует ли при проектировании учитывать то, что в данный момент не требуется? При проектировании следует учитывать бизнес-логику: как данные запрашиваются, как изменяются. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 07:40 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Создание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего?Тебе, что жалко, бро ? :) Это мизерные накладные расходы. Никто и не заметит. Если с т.з. разработки это поле действительно удобно/полезно, то его следует сделать. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 10:25 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  LSVСоздание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего?Тебе, что жалко, бро ? :) Это мизерные накладные расходы. Никто и не заметит. Если с т.з. разработки это поле действительно удобно/полезно, то его следует сделать. Да, да, ещё и кластерный индекс на это поле залепить, а на другие обычный. Не жалко ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 10:28 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  skyANAДа, да, ещё и кластерный индекс на это поле залепить, а на другие обычный. Не жалко Если в этом поле автоинкремент, то кластерный это норм.  зы: и тебе жалко ? :) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 10:42 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Юзер 01С одной стороны - накладные издержки на введение отдельного поля для PK минимальны. С другой стороны - следует ли при проектировании учитывать то, что в данный момент не требуется? Великолепное описание фактического состояния. Поскольку никаких показателей ни к одному, ни к другому варианту не имеется, ровно так и надо делать. Как? Да как хочешь. Хоть монетку подбрось. В конце эксперимента появится немножко опыта, который позволит в следующий раз без подсказок че-нить порешать. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 10:56 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Если говорить о чистой реляционной алгебре, то для связи N:N по определению достаточно двух полей, а третье без надобности. Другое дело, что мало какие реальные проекты имеют счастье жить в рамках чистой реляционной алгебры. И со временем, столкнувшись с практическими требованиями, многие приходят к мысли, что в каждой таблице PK должен быть одним полем, даже в таком простом случае. Некоторые причины тут уже назвали - репликация, протоколирование изменений, единообразная работа со ссылками, всякие сторонние инструменты, которые хотят PK как одно поле. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 11:31 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Cane Cat Fisher, +500. зы: применяю оба подхода, есличо. Но если в таблице много полей, то предпочитаю добавлять автонумератор. Для удобства. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 11:56 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  hVostt, мало плавал :) лучше любую связь рассматривать как М:М и при нужде наложить ограничение для сужения ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 15:07 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Извините, почему для репликации так уж необходимо, чтобы первичный ключ был только на одном поле? Если репликация основана на инструкции MERGE, то какая разница, что там у неё в JOIN CONDITION: Field1 = Value1 или Field1 = Value1 AND Field2 = Value2 ? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 15:52 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  ultrasonic7, Для МОЕЙ репликации так надо. У меня есть таблица "лог изменений" вида (id таблицы, id записи, тип изменения i/u/d), по этим данным формируется пакет изменений. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 19.02.2018, 16:40 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  ViPRoshVostt, мало плавал :) лучше любую связь рассматривать как М:М и при нужде наложить ограничение для сужения Звучит отвратительно даже в теории. Так то, ограничения foreign key -- злющее зло. Индексы -- надо бросать на все поля вдоль и поперёк. Всегда можно наложить ограничение в запросе, так? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 20.02.2018, 09:40 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  LSVskyANAДа, да, ещё и кластерный индекс на это поле залепить, а на другие обычный. Не жалко Если в этом поле автоинкремент, то кластерный это норм.  зы: и тебе жалко ? :)для USR_IN_GROUP да ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 20.02.2018, 10:08 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Шавлюк Евгений, собственный велосипед для репликации? )) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 20.02.2018, 11:10 | 
  
  
  
   | 
||
| 
 
Стоит ли делать отдельное поле для  PK? 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  bideveloperДа, тут отдельное поле для PK не нужно. А вот если бы это были строки заказа ) Насчёт строк заказа, так-то FK на позицию заказа это чисто дополнительная справочная информация. Заказ должен заморозить позицию, так, чтобы после того, как позиции товаров как-то менялись, это не повлияло на заказ. Либо записи товаров должны быть неизменными, любое изменение должно приводить к созданию новой записи. В общем, тут дело такое. Многие путают, не думая о системе в целом и обо всех аспектах функционирования системы. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 20.02.2018, 11:15 | 
  
  
  
   | 
||
| 
 | 

start [/forum/topic.php?fid=32&msg=39604654&tid=1540075]:  | 
    0ms | 
get settings:  | 
    9ms | 
get forum list:  | 
    15ms | 
check forum access:  | 
    3ms | 
check topic access:  | 
    3ms | 
track hit:  | 
    63ms | 
get topic data:  | 
    10ms | 
get forum data:  | 
    3ms | 
get page messages:  | 
    57ms | 
get tp. blocked users:  | 
    1ms | 
| others: | 246ms | 
| total: | 410ms | 

| 0 / 0 | 

    Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
    
    
    «На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
    
    
    ... ля, ля, ля ...