sp
У себя замечал - когда ссылка на таблицу Users присутствует в большинстве таблиц (т.е в миллионах записей) - практически невозможно чтоб не отвалился коннект у клиента из-за таймаута удалить юзера - это как пример

Это не повод, чтобы не использовать FK. Возможное решение в данной ситуации - удалять запись не физически, а логически (добавить в таблицу Users колонку Is_deleted, присвоить ей значение True, в запросах выводить данные с is_Deleted = False). Физически удалять эти записи можно в моменты низкой нагрузки, например, ночью или по выходным.

spМаксим НЕсли вы не будете использовать встроенную в БД поддержку ссылочной целостности (FK), то как будете решать это вопрос?

Ну MS делает же без FK и все работает!

В этом случае необходимы дополнительные затраты труда программиста для поддержки целостности данных.

spРассматривал на досуге структуру MSCRM
Много таблиц в которых есть столбцы из других таблиц (FK) но физически relations не созданы
Я так понимаю что при большом количестве связей БД начинает тормозить при операциях вставки, удаления, обновления
Так почему об этом MS нигде не пишет в качестве рекомендаций, хотя сама использует??

Отсутствие FK - часто встречающийся антипаттерн.

Почему в этой БД отсутствуют внешние ключи ?

Может, она была создана еще лет 15-20 назад. Тогда вопросы производительности стояли гораздо более острее, чем сейчас.

Может, ее создавали разработчики невысокой квалификации.

Может, это сделано специально, чтобы труднее было бы разобраться в структуре БД. (Особенно если колонки PK и FK имеют разные имена -- очень трудно разобраться, что с чем соединяется. Видел я года три назад такую БД в одном проекте.)
Например, в базе данных, которую использует для своих внутренних нужд Power Designer версии 15, не только отсутствуют все FK, но и таблицы и колонки имеют бессмысленные названия типа JKEWUIEW. Наверное, чтобы злые конкуренты не разобрались.

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

Что же касается влияния FK на производительность, то нужно сначала реализовать БД со всеми FK, посмотреть, влияет ли это где-нибудь на производительность, и только потом, возможно, какие-нибудь FK удалить. (А лучше не удалять, а сделать этому ключу disable, оставив его для документирования схемы БД). Опыт показывает, что для 80-85% таблиц в БД вопросы производительности не играют роли.