Сисой
В случае 1С отказ от контроля ссылочной целостности по первичному ключу вызван повсеместным использованием ссылок по recid. Ключи используются только в необъктных таблицах (регистрах).
Кроме того, используется ряд фокусов при организации распределенной БД. Например, при загрузке XML-файла с изменениями из одной БД в другую контроль целостности на уровне кода приложения ОТКЛЮЧАЕТСЯ (т.к. загружаемый объект может ссылаться на еще не загруженные в транзакции объекты). Это не есть гуд, но сделано именно так.
Кроме того, ограничения, накладываемые кодом приложения 1С на объекты БД (например, документы), иногда довольно сложны, носят нереляционный характер и в терминах стандартного Т-SQL будут занимать не одну страницу кода триггера (в 1С используются встроенные методы объектов). А если учесть, что 1С уже поддерживает 4 СУБД (включая свою файл-серверную), то проблема генерации триггеров для объектно-ориентированных или объектно-подобных мультиплатформенных ИС вызывает священный ужас разработчика (особенно если учесть часто возникающую необходимость интеграции триггеров с подсистемами задач/сообщений).
Плюс возможная несовместимость таких механизмов со следующими версиями СУБД.

Вот получется за счет универсальности доступа к данным построена модель БД, приводящая к крайне низкой производительности, но позволяющая программисту абстрагироваться от физической модели данных. Это очень хорошо, но... подвела реализация?.. Ну пускай в универсальной 1cv7s.exe не хватило сил или времени хотя бы сравнять производительность dbf и sql движка, но зачем в 8.x опять плодить один большой универсальный сервер приложений, поддерживающий 4 СУБД, включая свою собственную? Ведь опять теже грабли с производительностью в 8.0 что и были в 7.7, мучительно преодолеваемые в 8.1. Не проще ли было написать несколько вариантов серверов приложений, оптимизированных под нужную СУБД? Ведь трехзвенка и затевалась ради независимости от конкретики СУБД на стороне клиента... Есть возможность "выполнить метод на стороне сервера приложений", почему нет способа "выполнить метод на стороне сервера БД"? Вечный выбор - либо универсальность, либо скорость...

Ферзь Егоров АлександрЕсть возможность "выполнить метод на стороне сервера приложений", почему нет способа "выполнить метод на стороне сервера БД" ? Вечный выбор - либо универсальность, либо скорость...

Э что то вас понесло ..

это бывает. :) особенно когда требуется очередное многочасовое "восстановление последовательности" или "формирование внутренних продаж" и начинаешь откладывать ее до ночи или ближайших выходных... с ностальгией вспоминая самописку, в которой "последовательности" даже большего количества документов восстанавливались в течении нескольких минут. В том числе и благодаря возможности "выполнять методы на стороне сервера БД"... И не двух двухядерных ксеонах, а на обычном p-III...
Я понимаю - идеал недостижим. Но к 1С острая нелюбовь как раз по причине "ну разве можно так издеваться над sql-сервером???" А ведь сам начинал когда-то подсаживать людей на 1С именно из-за наличия готовых решений учета. Теперь у тех людей вырос документооборот и... предложить нечего. Либо монстров типа Ax\Nav\Sap, либо "кластеры северов", либо самописки...

svcoderЯ пока для себя нашел недавно только ОДНУ задачу, в которой бы мне пригодилось использовать foreign key constraint. Это замена дублей контрагентов.
Сразу хочется спросить, а разве нельзя заранее обеспечить уникальность справочника контрагенты? Если вы говорите, что логическая целостность базы - задача клиента, значит ваш клиент плохо написан, раз допускает дубляжи уникальных значений? Соответственно никакой гарантии логической целостности клиент не дает и даже помощи в этом не оказывает? в отличии от unique constraint по нескольким полям?