Прочитал из "ценных указаний". Насколько оправдана такая инструкция?
"Указания"Везде, где необходимо удалить более 1000 строк из таблицы нужно использовать механизмы, исключающие прямое удаление (например, переименование записей) и последующую сборку мусора в периоды низкой нагрузки на сервер.

Нельзя использовать Foreign Key. Все связи в таблицах должны обрабатываться в запросах операциями JOIN при чем предпочтительно использовать INNER JOIN и LEFT JOIN. В некоторых случаях можно использовать FULL JOIN. RIGHT JOIN использовать не нужно.

Для всех полей за редким исключением и особых случаев при создании таблиц нужно ставить ALLOW NULLS.

Не использовать никаких CONSTRAINTS кроме Default Value.

Не использовать триггеры.

dab2,

"Нельзя использовать Foreign Key"

все эти "нельзя" не имеют смысла в общем случае. все хорошо в своей области. если мы пишем систему критическую по связанности данным, то нельзя БЕЗ форейн кеев. поэтому лучше сразу учтонять "в случае двх, не рекомендуем использовать форен кеи"

Механизм массовых вставок умеет игнорировать все констрейнты, bcp это делает по-умолчанию.
И получится свой механизм, повторяющий работу FK.

А почему можно использовать Left join, но нельзя Right join?

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

Декларативную целостность и придумали в том числе и для того, чтобы избавиться от контролеров.

Все равно нужен будет контролер, который будет проверять на следование шаблонам, иначе получится полная дичь даже с 2мя разработчиками.

Реальная система пишется многими людьми долгое время. Эти люди разной квалификации, и, если система сложная, не знают весь код.

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

Ссылочная целостность не гарантирует отсутствие ошибок вообще, но защищает хотя бы от части ошибок.

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

В ОЛТП замедление не такое большое, не "в разы".
А вот в DWH ссылочная целостность может помешать максимально быстрому балк инсёрту, поэтому её часто не используют, но только для тех огромных таблиц, в которые нужно вставлять максимально быстро - и в том случае, если целостность не стоит дополнительных затрат на железо.

Т.е., в итоге, ваши рассуждения совершенно правильные, но не правильно обобщать на уровне "Для хранилищ данных -- абсолютно правильная и оправданная инструкция. Тригерры, внешние ключи и прочие констрейнты -- в DWH элементы чужеродные".
И так же неправильно правило, которое озвучил ТС: "Нельзя использовать Foreign Key". Очевидная низкая квалификация команды, независимо от того, DWH они делают, или OLTP. ИМХО "старая школа", 30 лет назад это было модно.

a_voronin,

А генератор кода кто напишет?

Смысл такой, что всю эту внешнюю целостность надо проверять на других уровнях, - когда формируется stage, когда определяется, обрабатывается и передается относительная небольшая дельта в КХД, либо полностью перекладывать на ИС.

Вот, к примеру, если изначально ХД основывается на источнике 1С, и там уже построены все внешние ограничения, - зачем делать это еще раз, повторять на уровне DWH? Если у нас не генерятся новые строки, а если и генерятся - то подчинены всем правилам SCD, - то смысл на основном большом массиве данных проверять внешнюю целостность каждый раз? Пусть уровень stage это хотя бы делает - он хоть работает с малым набором данных, и пусть поставляет очищенные и отвалидированные данные в основную, рабочую область

a_voronin,

Да-да, все верно, такая ситуация может так же возникнуть

Я когда-то с таким решением работал: все операционные источники стекались на сервер с инстансом DWH через AlwaysOn - т.е. - их secondary-базы в асинхронном режиме были актуальны с master-репликой, где были писатели/читатели.
В момент, когда требовалось прогрузить дельту в КХД - на secondary-базы, которые были в открытом состоянии и аплаили журнал транзакций - приходила команда на создание snapshot'а.
И, таким образом, на время обработки инкремента Хранилищем, - оно работало с замороженными на момент до начала операции данными в снепшоте, поэтому там не могла случиться ссылочная нецелостность, когда часть таблиц отработали, а в часть справочников уже залились обновленные/новые строки, и FK мог не отбиться.
Ну и весь ETL так же смотрел на снепшот, получается, которые динамикой создавался, дропался и переобновлялся в свою очередь

У вас описан так же частный случай этой ситуации, - но обработать-придумать что-либо можно