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

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


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

Да. Именно так.

ViPRos"что если под этой таблицей развесистый кусок" - а это всегда так, если это не курсовая

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

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

Создание в таблице связи отдельного поля PK приводит к необходимости создания и ведения дополнительного уникального индекса. Ради чего? Потому что кто-то там не может репликацию настроить? :)

bideveloperДа, тут отдельное поле для PK не нужно.
А вот если бы это были строки заказа )

Дык это уже тогда и не М:М :)

ViPRoshVostt,

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

Звучит отвратительно даже в теории. Так то, ограничения foreign key -- злющее зло. Индексы -- надо бросать на все поля вдоль и поперёк. Всегда можно наложить ограничение в запросе, так?

Шавлюк Евгений,

собственный велосипед для репликации? ))

bideveloperДа, тут отдельное поле для PK не нужно.
А вот если бы это были строки заказа )

Насчёт строк заказа, так-то FK на позицию заказа это чисто дополнительная справочная информация. Заказ должен заморозить позицию, так, чтобы после того, как позиции товаров как-то менялись, это не повлияло на заказ. Либо записи товаров должны быть неизменными, любое изменение должно приводить к созданию новой записи. В общем, тут дело такое. Многие путают, не думая о системе в целом и обо всех аспектах функционирования системы.

Wlr-lНеобходимость создания и ведения уникального индекса состоит в том, чтобы в таблице USR_IN_GROUP не появились, например, такие строки
...
1000, 1, 1
...
2555, 1, 1
...

С реляционной точки зрения, это важнее всего остального.

Эммм.. и что? PK является таким индексом и хранится в таблице, не создаёт лишних накладных расходов. Я понимаю, когда без них никак. Но зачем нагружать БД тем, без чего прекрасно можно и нужно обходиться?


Wlr-lЧто касается заказов, то "Каждый заказ может содержать одну или несколько позиций, каждая позиция может принадлежать одному и только одному заказу". Где здесь М:М вместе с заморозкой позиций? FK всего лишь говорит, что ЭТА позиция принадлежит ЭТОМУ заказу, а не ТОМУ. Без всяких других аспектов функционирования системы.

Мозги не думать. Понятно.

fkthatЗнавал одних чуваков, так когда у них с БД что-то не пошло и решили, что все из-за того, что при выборках слишком много джойнов, так они вообще все таблицы со всеми связали по FK

Ну, я же говорил, FK -- зло

ViPRosСвязь - всегда сама по себе.

Проблема вот в этом утверждении. Как только связь становится «сама по себе» и создаётся на какой-нибудь отдельной вкладочке «Связи» — это колхоз и выливается 100% в систему, которую с какой стороны не тронь, всё пойдёт по п.....е.

Связь это отношение, т.е. характеристика конкретного объекта. С обоих сторон она должна выражаться определением этого объекта.

А то ты так свяжешь агрегат автомобиля с категорией холодильников, и всё выглядит здорово, только у пришедшего аналитика возникают вопросы, где взять канистру с бензином, чтобы всё нахрен сжечь и посадить на кол колхозников-разработчиков.

Wlr-lЕсли все хорошо в многомерном пространстве, то как это будет в одномерном? Можно объяснить на примере заказа и позиции? Особенно в динамике, когда "связь сама по себе".

Да у него в его системе для «всего и вся» связи ведутся и управляются отдельно.

Тем же колхозным путём пошли и разработчики Галактики.

К слову, на 3-х часовой демонстрации возможностей Галактики, самый главный эксперт уже через час, когда показывал самые простые вещи и азы, стал теряться и путаться, по десять минут лазая по вкладочкам, коих миллион и табличкам, коих миллион, чтобы сделать простейшие с точки зрения бизнеса вещи. Адище в общем.

Wlr-lКак обеспечить уникальность пар USR_ID и USR_GROUP_ID, если есть ключ по ID?

я как раз против дополнительного суррогатного ID.
в таблице связи он как третье колено.
и всякие «репликации» — очень плохая отмазка. очень.

LSVЭтим путем пошли почти все создатели взрослых ERP систем. Внезапно (с)
Я даже не знаю, есть ли среди ERP систем, где не применяют этот колхозный путь. Мне таковые неизвестны.
Мож ты знаешь ? :)

мы разработали такую систему, решающую задачи уровня галактики.
у нас ни намёка ни на какие отдельно стоящие «Связи».
если какая-то бизнес-сущность имеет связь с другой, это непосредственно её характеристика.

у нас есть внедрение на федеральном уровне в сфере энергетики. и несколько региональных.

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


LSVзы: Уже была недавно такая тема про ФК (нужны/не нужны).

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

ViPRosСвязь не характеристика объекта.
Это объект, который связывает объекты.

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


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

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