LSVНу очевидный же ответ: такая запись должна иметь признак "неактуален".
Может иметь такой признак, а может иметь признак "архивная", или ещё какой, но при этом пользователь хочет иметь возможность её удалить с корнями.

Зачем его ограничивать, если это его данные и он суперадмин, или член совета директоров?

Вы ещё скажите, что всю электронную переписку храните за последние 10 лет :)

buvenskyANAИ это кстати пример того, что не надо опыт разработки вашей системы переносить на все остальные.

В том то и дело, что вопрос ТС был общий и на самом деле до сих пор нет внятных аргумент за, как заметил LSV.
Вспоминается история времен зари перехода наших банков на забугорные АБС, когда представители вендора сильно округляли глаза, услышав, что одно из требований - возможность удалить проводку. И пришлось им таки это реализовывать в итоге.
Это к тому что не важно, какая система. На вопрос топика "Нужно ли связи в таблицах в sql?", ответ: если хочешь - конечно нужно, но особого профита от них не жди, и будь готов к возможному геморрою, связанному только с ними.
А какой такой ОСОБЫЙ профит Вам нужен-то? :)
Написали уже зачем нужен FOREIGN KEY и какие бывают причины нарушений ссылочной целосности.

Если у Вас с этим нет проблем, или Вы используете какие-то там признаки, или триггера, или специальным кодом обкладываете, так флаг Вам в руки :)
А мы вот используем родной механизм СУБД и проблем с ним не встречали и не встречаем.

LSVЕсть правила построения ИС.
О каких правилах речь? Ссылку дайте.

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

LSVskyANAО каких правилах речь? Ссылку дайте.ОК.
тынц :)
Что-то похоже на то, что Вы юлите. Где конкретно Дейт пишет, что не должно быть штатной возможности удаления в Б/Л?

А вот тому, что Вы отрицаете, он посвятил целую главу :)

LSVskyANAЧто-то похоже на то, что Вы юлите. Где конкретно Дейт пишет, что не должно быть штатной возможности удаления в Б/Л?существенно дополню: удаления с нарушением СЦ .
По хорошему - не должно быть.Да, не должно быть. И ограничения СЦ это гарантируют.

LSVНо если "очень нужно", то можно. :) Главное помнить про это.Если "очень нужно", то можно отключить проверку ограничений, сделать то, что "очень нужно", включить проверку обратно.
И не надо ничего дополнительно помнить, документировать, кодить.

LSVВсё, что пишут всякие Дейты, Чены и прочие Конолли это не более чем теория и рекомендации.Вы сами привели ссылку на Дейта, и сами же от неё открестились. Вы право, чудак :)

LSVВ любой более-менее большой инф. системе можно найти отход от канонов. Это нормально.С этим не спорю. Но сложилось впечатление, что Вы свой "отход от канонов" выдаёте за истину в первой инстанции :)

LSVskyANAС этим не спорю. Но сложилось впечатление, что Вы свой "отход от канонов" выдаёте за истину в первой инстанции :)Впечатление складывается у не в меру впечатлительных. :)Шутка на 2 балла :)

LSVВыдаю не за истину в первой инстанции, а всего лишь за бест-практис с описанием случаев применимости. И не более.Это не бест-практис хотя бы потому, что в описанных Вами случаях ограничения СЦ не создают никаких проблем.

LSVИ не надо ничего дополнительно помнить, документировать, кодить.Как это не надо ? Надо, бро... Не везде можно установить СЦ, поэтому надо всегда помнить, где она есть, а где нет.Я ему про Фому, он мне про Ерёму :)

Ещё раз: если использовать штатный механизм СУБД, то не надо пилить свой велосипед, документировать его и помнить о нём - это же очевидно.

А "не везде можно" - это уже к вопросам проектирования и умению пользоваться.
Повторюсь, что те примеры, которые Вы приводили не тянут на "не везде можно".

"удалять вопреки всякой логике" - это Вы о чём?

А "не удалять совсем"...

У меня это было реальное требование во времена разработки АИС ТПС, после того как в одном из регионов один из операторов удалил не те данные.
Правда звучало оно не "не удалять совсем", а "на самом деле не удалять, а помечать как неактивные".
Для оператора это выглядело как удаление, а пользователи с более широкими правами могли как восстановить, так и "удалять совсем".

LSVskyANAесли использовать штатный механизм СУБДЭтого механизма для сохранения целостности Б/Л в общем случае недостаточно.
О чём конкретно речь? Можете пояснить, что за целостность бизнес логики такая?

LSVЯ не знаю ниодной известной тиражной системы, где это применяется.Хм, Мастер-Тур. Очень даже известная тиражная система в своей нише.

982183skyANAВы ещё скажите, что всю электронную переписку храните за последние 10 лет :)
Переписка, бухгалтерские проводки, логи с электронной проходной.
С 1995г храним . . .
А Вы лично тоже храните свою переписку за последние 10 лет? Любой спам?

azsxавтор"удалять вопреки всякой логике" - это Вы о чём?
Простой пример. Две таблицы, 1 табл. поля: фио + город; 2 табл. поля: фирма + город. Город может поменять название или объединится с другим (удалиться).
По моему мнению контроль на уровне одинаковости названий городов нужен. Третья таблица - города, внешний ключ с двух таблиц. И null для города недопустим.
Причина, так как админ софта "на местах" убъётся, но заставит дать ему права root от БД, так как он ж программист и sql знает. И он обязательно найдёт причины по которым надо править и удалять города напрямую прямо в таблице и обязательно в первом варианте не подумает, что надо править не только в таблице с фио, но и в таблице с фирмами.
Я могу понять зачем вы это делаете на уровне разработчиков (сам любитель).
В фирме, которая пишет софт эффектный менеджер, который заставил внедрить в софт фичи "шьёт, жнёт и на дуде играет" и БД и логика в программе очень усложнена. Также программистам платят мало, они бегут как тараканы. Нафиг в такой фирме усложнять sql логику, пусть админы правят всё что хотят, типа им же хуже.
Извините, но ни фига не понял. Такое впечатление, что Вы просто эмоции выплёскиваете :)

azsxИ он обязательно найдёт причины по которым надо править и удалять города напрямую прямо в таблице и обязательно в первом варианте не подумает, что надо править не только в таблице с фио, но и в таблице с фирмами.
Вот тут (если использовать ограничения СЦ) ему СУБД скажет, что удаление не возможно, так как есть ссылка на город из таблицы с фирмами.

Но повторюсь, что я так и не понял при чём тут "удалять вопреки всякой логике". Вроде логика ясна: надо "склеить" две записи об одном городе в одну.