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Детали в разных изделиях, даже если их параметры полностью идеинтичны,
Вот как раз тут стоило бы думать о хорошей структуре базы.

stenfХорошо, открываем Кена Хендерсона
Если честно, не в курсе кто это, а характеристика на основании быстрого поиска по гуглю вряд ли будет объективной.

stenfВ поле IDИзделия таблицы Детали для нулевой сборки вставляю null.
Oops. Мы же с этого начали - Вы начали отказываться от null, я начал показывать, что последствия будут хуже. Как только Вы решаетесь таки использовать null, все становится легко и просто.

stenfУтрирование в данном случае - это применение нерелевантного сравнения.
Вполне релевантное в рамках того, что я хочу объяснить.

stenfЗачем приводить в пример нарушение логической целостности базы внутри транзакции и нарушение целостности, при котором в таблицу вставляются значения, которых там по бизнес правилам быть не должно, а вы просто договорились с сервером, что "ща погоди, следующий оператор все поставит на свои места" ?
Потому что то и другое - нарушение целостности. Целостность не есть атрибут конкретного оператора, конкретной записи итп. Это атрибут базы в целом. В ходе транзакции допускается нарушение "целостности снапшота" с условием, что к концу транзакции целостность будет восстановлена.

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

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

stenfВообще я тут не критикую deffered constraints, просто применение этого "маленького чудовища" тоже бы неплохо ограничить действительно необходимыми случаями, а данный случай имхо не является таковым.
deferred constraints - это действительно не то чтобы хорошая штука. Но лучше, чем их отсутствие :) В условиях задачи "без null" без них было не обойтись; с null они не нужны.

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

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

stenfоднако очевидно, что такие случаи надо сводить к минимуму, а не плодить их
stenf, Вас никто не призывает их плодить. Вы сами пришли к тому, что null здесь нужен, так нафига теперь придумывать за меня наивные концепции?

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

Есть бизнес-правила. Например "каждая деталь должна принадлежать изделию" или "дебет должен сходиться с кредитом". Их можно считать условно равноправными, а если считать разновесными - веса определяются только бизнесом и ничем другим.

Каждое из этих правил может контролироваться различными способами. Скажем, первое я могу контролировать триггером, писать код, а второе - через materialized view, без всякого кода.

Внешний ключ - это механизм проверки бизнес-правил. Стандартное, удобное решение. Ничего более, никаких "структурной целостности основ". С практической точки зрения нарушение баланса может быть во всех отношениях гаже, нежели нарушение внешнего ключа, это зависит только от бизнеса, а не от того, какие проверки авторы СУБД предусмотрели, а какие нужно реализовывать руками.

Сугубо технически я даже могу организовать ситуацию, при которой существует и активен внешний ключ, но в таблицах лежат нарушающие его данные. Хотя именно для внешних ключей смысла в этом пожалуй нет, это удобно для check и notnull constraint-ов.

stenfхех, я-же ваши примеры цитировал 8)
Really? :)

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

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

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

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

stenfхм, несколько null-полей в таблице это называется не плодить ? Или это каким-то образом способно оградить меня от более серьезных ошибок ?
Хм. Прежде всего, "несколько" - это довольно бессмысленная категория. С точки зрения
"возможной опасности null" поля можно разделить на три категории:

Участвующие во внешних ключах. "Неожиданный" null способен привести к пропаданию нужных строк из выборки.


Участвующие в расчетах. "Неожиданный" null способен испортить результат какого-нибудь вычисления.


Просто хранимые поля. null совершенно не страшен (до тех пор, пока на клиенте не применяется какой-нибудь тупой ORM, не решивший корректно вопрос работы с null-полями).

Практически первая названная ситуация, пожалуй, наиболее тяжелая с точки зрения встречающихся последствий. Вторая выглядит куда гаже, но тут я позволю себе сослаться просто на свой опыт - такое встречается крайне редко, я пару раз встречал рассказы о таких ситуациях, а в личном опыте так по-моему ни разу. Скорее всего, дело в том, что такие ситуации в 99.9% случаев приводят к null-результату вычисления и ошибке cannot insert null into not-null field, то есть отлавливаются сразу и не приводя к существенным проблемам.

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

stenfВот смотрите. Есть положим система учета платежей за телефон. .....
Хм. Как раз в той "системе без null", с которой пришлось возиться, я в какой-то момент обнаружил около 50.000 записей "банковских счетов", не привязанных к банкам. Как потом выяснилось, с этими данными была какая-то проблема при импорте, их криво затянули, в итоге они были привязаны к "неизвестному банку" - и как ни странно, никаких проблем это не доставляло. Я обнаружил это уже на этапе "любознательности", когда исправив явные проблемы, рыл базу в поисках потенциальных.

stenfОднако вполне может так оказаться, что являясь нашим лучшим клиентом, мы хотим подарить ему бесплатные минуты.
Если мы хотим подарить бесплатные минуты, это должно быть учтено в структуре БД. Если мы начинаем корежить данные с целью добиться нужного результата, это не "безобидная шалость", а "одна из самых больших проблем, какие только можно создать".

stenfОднако никакое бизнес-правило не может измениться так, что-бы счет оказался "в воздухе", так как это противоречит физической реальности.
Смотря что Вы называете "в воздухе". Если "ссылающийся на отсутствующую запись", это конечно плохо, потому что правильнее сделать ссылку на null. Счет "неизвестно для кого" не есть хорошо, но может потребоваться, когда выставляется он таки действительно неизвестно на кого. Зачем такой? Cкажем, для того, чтобы бухгалтерия принимала по нему решение, в то время как система не попыталась выставить счет на те же услуги в следующий раз.

stenfГрубо говоря, вы можете быть уверенным, что физическая реальность не является изменчивым бизнес-правилом и будет неизменна сколь угодно долго.
Cуществование "физической реальности" - это тоже заблужение :)

stenfreally-really :)
Hmm.... Can you make тынц?

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


stenfпотому-что это усложняет сопровождение программ и является потенциальным источником ошибок. Это как множественное наследование в ООП, может и хорошее изобретение, расширяющее возможности программиста, только вот например Steve McConnell (не дай бог скажите что теоретик) советует держаться подальше от такого счастья,
Ага. Стандартный подход программиста на Visual Basic.

Но лично мне ближе мнение Джоэля. Куда проще проверить, способен ли человек работать с указателями (тоже одна из концепций, требующих винтиков в голове) и не брать тех, кто не способен.

stenfОткуда-же я знаю, наверно это их и стоит спросить. Собственно, может где-то это уже и опубликовано, если это является таким ценным алгоритмом
Ну спросите. Я же почему-то думаю, что ценным алгоритмом это не является :)

stenfМожет это какой-то хитрый логический ход, но мне кажется странным агитирование за null при помощи демонстрации его недостатков.
Я не агитирую. Я "рассказываю как есть", и преимущества, и недостатки, а право идти мимо брода и тонуть полагаю Вашим и неотъемлимым.

stenfВот. Представляете теперь, какой кошмар мог-бы произойти, если-бы там еще и null были ?
Наоборот. Если бы там были null, этих 50.000 левых записей просто не было бы. Они висели исключительно для того, чтобы внешние ключи куда-то ссылались.

stenf softwarer
Если мы хотим подарить бесплатные минуты, это должно быть учтено в структуре БД

Вы не поняли мой пойнт. В первоначальных требованиях никаких бесплатных минут могло и не быть.
Это Вы не поняли, что я Вам сказал. Если в первоначальных требованиях бесплатных минут нет, а теперь они появляются, их надо адекватным образом встроить в структуру БД. В том числе в бизнес-правила. А любого, кто попробует как предлагаете Вы, "вот здесь хакнем данные, и ничего страшного не случится" следует распять на двери отдела тестирования.

stenf softwarer
Если мы начинаем корежить данные с целью добиться нужного результата, это не "безобидная шалость", а "одна из самых больших проблем, какие только можно создать".

не понял, как корежить ?
Так, как Вы предлагаете. Вольный пересказ Вашего предложения: "есть система, где дебет сходится с кредитом и нет бесплатных минут. Мы хакаем данные, добавляя бесплатные минуты, а то что дебит при этом разойдется с кредитом так нестрашно".

stenfЯ не знаком с разработкой систем для банков,
При чем тут банки?

Счет в данном контексте - это такой документ, который выставляется покупателю товаров или услуг.

stenfно со стороны такое решение напоминает удаление гландов через задницу. Такие "хитрожопые" решения опять-таки усложняют сопровождение, что плохо по определению.
В моей системе я не собираюсь допускать существование детали "подвешенной в воздухе".
Безусловно, плохо. И я упомянул это только для того, чтобы объяснить: даже в плохих ситуациях система при этом выживает.

Вы изначально хотели вещь куда хуже. Зацикливание. Могу повторить еще раз: как только Вы согласились отказаться от нее и ввести null, вся эта ветка теряет особый смысл.

stenf softwarerCуществование "физической реальности" - это тоже заблужение :)
ну надо-же во что-то верить, я предпочитаю верить в обьективную реальность вокруг меня :)
Видите ли в чем фокус, объективная реальность вокруг Вас не то чтобы однозначно связана с тем, что Вы проектируете. Вы проектируете виртуальный мир, и как он отображается на реальный и наоборот - вопрос Вашего выбора, ничего более.

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

Кстати, ища материал для тынца, нашел у Вас замечательную фразу, ранее несправедливо пропущенную:

stenfСамой базе будет глубоко фиолетово, если на счет не поступят деньги, списанные с другого счета.
Вот! Это страшная, недопустимая точка зрения, и именно поэтому Вы думаете, что foreign key - основа.

Поймите, данные - не просто "самое ценное, что есть в базе". Это на самом деле единственная ценность, которая там есть. Неверные данные - куда хуже неверной структуры. Смотря с точки зрения "самой базы", Вы выступаете с точки зрения небезызвестного персонажа Райкина, вопрошавшего: "к пуговицам претензии есть?".

Видите ли, программа создается ради пользователя. Пользователю - например, автомобиля - нужно, чтобы "машина ехала", и ничего более. Вы, как профессионал-технарь, можете знать, что для того, чтобы машина ехала, у нее должны быть накачаны колеса, но недопустимо проводить подмену понятий, подмену пользовательского удовлетворения (машина едет) техническим аспектом, никому кроме Вас неинтересным. Говоря "самой базе глубоко фиолетово", Вы говорите примерно следующее: "главное - чтобы колеса были накачаны, а то что машина не едет, так самой машине это глубоко фиолетово".

stenfсмешно, но вы сейчас чуть не слово в слово цитируете так не любимого вами Джо Селко.
Вы переоцениваете мое к нему внимание.

Я цитирую общеизвестный факт, чуть менее общеизвестный, нежели "солнце встает на востоке". То, что его цитирует еще и некто Селко, мало что меняет.

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

stenfпоздравляю, вы движитесь против основных течений в современном программировании.
Есть одна старая и довольно известная фраза:

Hе иди по течению, не иди против течения, иди поперек него, если хочешь достичь берега.

Лично я полагаю еще более правильной следующую концепцию:

Hе иди по течению, не иди против течения, иди туда, куда тебе надо.

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

Пытаться обходиться без null можно по-разному. Например, наиболее корректным путем будет введение дополнительных сущностей; "необязательность" будет выражаться отсутствием строки в этой дополнительной таблице. Подход плох несколькими вещами: во-первых, большим количеством ненужных join-ов, во-вторых, тем, что надо постоянно помнить о необходимости использовать с этой таблицей outer join, наконец, в лишних тратах на эти дополнительные таблицы.

stenfCan you make тынц? (C)
Странно Вы как-то поступаете. Мою просьбу не выполняете, но сами тут же просите то же самое.

stenfна подобные мои высказывания ? Особливо про "хакнуть данные" please.
Даже в страшном сне мне не могла приснится такая интерпретация моих постов
Давайте смотреть. Ваши слова, в контексте обсуждения бизнес-правила соответствия дебета кредиту:

stenfОднако вполне может так оказаться, что являясь нашим лучшим клиентом, мы хотим подарить ему бесплатные минуты. Если при проектировании системы вы включили в систему проверку на соответствие прихода/расхода - то БД просто не даст нам совершить этот великодушный поступок.
То есть, Вы строите ситуацию: есть бизнес-правило, мы хотим "подарить бесплатные минуты", бизнес-правило этому препятствует. И общий контекст - это бизнес-правило нестрашно нарушить, вот один из примеров, когда нарушить его можно и нужно.

Это я и называю "хакнуть". В противовес нормальному подходу: учесть новое требование и доработать под него систему.

stenfнэправда. Ничего подобного я не хотел.
"Сознательно не хотели". Комплекс выдвинутых Вами требований не оставлял другой возможности, строго математически.

stenfтут есть важная оговорка, в связи с тем, что сопровождать пьяного розового слона придется другим программистам, необходимо что-бы всем остальным такая абстракция тоже казалась очевидной,
"Очевидной" - неудачное слово. Скорее "уместной и адекватно документированной".

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

stenfА так как такие слоны в реальном мире не водяться, то у разных людей будет свое представление о розовых слонах и их повадках, и следовательно в первом приближении такая абстракция не то, что-бы хорошая идея.
Ох, а уж какая не то чтобы хорошая идея, например, "аналитического счета".....