_модChAСледовательно, бесполезна и декларативная ссылочная целостность.Если атрибут сущности есть ссылка на другую сущность, то необходимо обеспечить отсутствие битых ссылок.До тех пор, пока это касается только пары соседних отношений, не вопрос. Но переходя на уровень БД в целом и отказываясь от составных ключей, автоматически отказываемся от одной из удобных возможностей обеспечить логическую непротиворечивость данных стандартными механизмами СУБД.
Я ведь не зря дал эту ссылку . Типичная ситуация, возникать может совершенно с разными "действующими лицами". В случае варианта BF , проверка на участие работника только в проектах "своей" организации(или подразделения в рамках одной организации, не суть) лежит на СУБД. При любой попытке подключить его к плану "чужой" организации сработает ограничение по FK.
Вариант Fabian Pascal будет честно отрабатывать только на "соседей", обеспечивая, так сказать, целостность на уровне домена, но зато в таблице участников проекта может запросто оказатся противоречивая информация, т.к, формально, работника легко подключить к проекту "чужой" организации. При этом, он был вынужден добавить ещё одну сущность, чтобы остаться в рамках атомарности ключей.
_модКто и как это будет делать - вопрос второй.В этом, IMO, и заключается основное противоречие между "остроконечниками" и "тупоконечниками". Мне более правильным кажется подход, когда непротиворечивость данных в БД, по максимуму, держится на стандартных механизмах декларативных ограничений. Это последний бастион, так сказать. И в этом случае, составные ключи могут играть очень важную роль, в том числе, и повышая производительность определённого вида запросов. Понятно, что это не панацея от всех бед, так как не все ограничения бизнес-логики возможно решить декларативно на уровне современных РСУБД. И хотя в стандарте SQL 2003 появились любопытные, на первый взгляд, вещи, которые могли бы улучшить ситуацию, но, судя по темпам миграции ведущих игроков на рынке РСУБД в сторону стандартов, боюсь, они нескоро войдут в стандартный арсенал.
Вы же, насколько понимаю, сторонник упрощённого подхода и большинство проблем с непротиворечивостью данных на уровне БД, может за исключением самых простых, готовы решать процедурно. У меня он не вызывает принципиальных возражений, если грамотно реализован, но это, скорее, исключение, чем правило. Был неоднократным свидетелем картины, когда проектировшик БД, похоже, полагал, что его роль заключается в простом добавлении во все таблицы атомарного суррогатного ключа и дело в шляпе. Всё, что потом натягивалось на это сверху, выглядело нисколько не лучше. Результат был предсказуем, в данных можно было найти немало "мусора", что подчас приводило к странного вида запросам, например, активного использования DISTINCT.