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 выделяется в отдельную сложную многогранную, как душа неотёсанной девственницы, сущность. которую надо отдельно вести и поддерживать. это колхоз.