stenfКак быть ?
Я могу назвать как минимум три варианта.

1. Совместить таблицы деталей и изделий.
2. Воспользоваться deferred constraints.
3. Пробивать информацию в два приема: insert в изделия - insert в детали - update изделий с установкой id детали.

stenfполучиться избыточность
Не получится. Точнее, если Вы полагаете избыточностью любое поле, допускающее null, Вам придется чуть ли не для каждого поля заводить отдельную таблицу.

stenfхотелось-бы все-таки обеспечить ссылочную целостность структурой базы, а не хитрыми финтами ушей
Хм. Интересно, Вы вообще думаете, о чем говорите?

stenfНеужели обиделись ? Вот уж не думал.
Да нет, просто удивляюсь.

stenfИзбыточность в первом случае есть
Избыточность, точнее "логическая избыточность в Вашем смысле этого слова" есть в случае любого поля, допускающего null-значения. Рассмотрите, скажем, позиции товарных документов, ряд полей которых (отпускная цена, кладовщик, серийный номер) заполняются только при отгрузке. В принципе их можно было бы так же распилить - на "позицию" и "данные по отгрузке позиции". Технически любую схему можно преобразовать в эквивалентную без подобной избыточности, это будет даже давать некоторые преимущества, скажем возможность легко реализовать ограчинения вида "если введено A, должны быть также введены B, C и D". Но на практике это будет зверски неудобно.

stenfUpdate после вставки не даст установить внешний ключ на это поле (а он тут нужен),
Ччего, простите?

stenfdeffered constraints не знаю есть-ли в mssql
Были какие-то. Но это лучше смотреть на месте.

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

Представьте себе любую транзакцию, состоящую более чем из одного элементарного SQL-оператора. Можно быть почти уверенным в том, что в момент "между операторами" данные не являются целостными (скажем, с одного счета списали, на другой еще не записали). И что же, все, капут рыбке, решение неидеальное?

stenf softwarerНо на практике это будет зверски неудобно.
Я могу вам привести цитату Джо Селко:
Селко, при всех его многочисленных достоинствах, не совсем практик. Кроме своих достоинств он обладает также одним из моих, а именно склонностью к экстремальным точкам зрения. Это и приводит к этой цитате, порожденной, как я слегка подозреваю, рефлексами работы в dbf-овские времена.

stenfТак что я стараюсь избавляться от null'ов, и имхо с этой точки зрения ввод в таблицу сразу нескольких полей с null нецелесообразно.
С моей точки зрения таблицы (как и другие артефакты проектирования) прежде всего должны быть удобной терминологией описания предметной области. С этой точки зрения предлагаемая Вами структура.... настораживает, и имхо больше нуждается во внимании, нежели формальные критерии.

stenfваши слова "insert в изделия - insert в детали - update изделий с установкой id детали.".
Мои. Внешние ключи при этом нормально работают.

stenfПри инсерте в Изделия деталь неизвестна, что вы там будете вставлять в поле IDДетали, если там стоит внешний ключ на Детали ? Подозреваю, что вы мне сейчас предложите null.
Однако давать разрешение столбцу иметь null, хотя там ни один null не должен будет появляться (за исключением короткого момента между двумя вышеуказанными операторами) является логическим кошмаром.
Из двух ссылок хотя бы одна должна допускать null по той простой причине, что иначе неизбежно потребутся пары, закольцованные друг на друга, либо циклы [не советую пытаться опровергать - это тривиально доказывается строго математически]. В Вашем случае это будет означать "изделие является собственной деталью", что есть даже не логический кошмар, а просто объективный бред. С этой стороны и начинайте вставлять записи с null.

stenfКроме того, как известно ружье висящее на стене рано или поздно выстрелит, а в столбце допускающим null'ы рано или поздно этот null появиться, что приведет к сбою клиентского приложения, причем неприменно в момент демонстрации его заказчикам.
То есть Вы предпочитаете циклы в иерархии компоновки? Ну... удачи Вашим заказчикам, и главное терпения.

Впрочем, даже в такой - имхо, не то чтобы удачной - постановке задачи она запросто решается теми же deferred constraint-ами. Получаете два id, вставляете записи в базу в любом порядке.

stenf softwarer
Представьте себе любую транзакцию, состоящую более чем из одного элементарного SQL-оператора

Вы утрируете.
Чего, простите? По-вашему, транзакция из нескольких операций - это утрирование, в жизни такого не бывает?

stenfВ случае транзакций вам некуда деваться.
Ой, да что Вы говорите :)

Кстати, а что за "в случае транзакций"? В приличных СУБД случаев без транзакций не бывает.

stenfВ данном случае можно найти выход, придумав хорошую структуру базы.
Если Вам охота извращаться, убирайте прямую ссылку между деталями-изделиями и делайте еще одну, имперсонифицирующую таблицу-развязку. Примерно так:


stenfЯ не могу допустить появления одного и того-же IDДетали в разных изделиях, даже если их параметры полностью идеинтичны,
Вот как раз тут стоило бы думать о хорошей структуре базы.