sp,

От предметной области/задачи зависит, наверное. Но мне не встречались задачи, где данные надо удалять из базы. Другими словами - то, что в базу попало, оттуда уже никуда не пропадает. Релизую где через флаг активности/видимости/актуальности, где через поле статуса (активен - в архиве - удален), где через период актуальности - в зависимости опять же от задачи. Но не удаляю никогда. И никогда не встречал проблемы уникальности где бы то ни было, а не только в справочниках. Более того, даже не могу понять, откуда этой проблеме взяться.

spmiwaonline,

проблема с уникальностью может возникнуть когда запись у вас "удалена" и создана еще аналогичная запись.
При попытке "удалить" ее - у вас и возникнет проблема уникальности!
С какого перепугу? Данные при попадании в таблицу получают идентификатор; его уникальность гарантировано обеспечивается внутренними механизмами используемой СУБД. А дальше, «если клиент идиот», он может хоть миллион одинаковых значений внести; все равно они будут иметь разные идентификаторы. Ну или постелить соломки для таких уникалов и подсказывать: есть, мол, тут такая же запись, только удаленная - может, восстановим ее вместо создания новой?

vadiminfospmiwaonline,

проблема с уникальностью может возникнуть когда запись у вас "удалена" и создана еще аналогичная запись.
При попытке "удалить" ее - у вас и возникнет проблема уникальности!
На самом деле " у вас "удалена" и создана еще аналогичная запись" - это, в силу природы вещей, каждая операция UPDATE.

Поэтому это не только

zeon11Это привет горячий всем любителям естественных ключей.

Но и любители суррогатных тоже без приветв не останутся, скорее всего.

А можно хоть приблизительный сценарий такого привета?

spне горячитесь вы так - поспокойней)

А где я горячился?

spесть табличка в которой храним, к примеру - список каких-либо коэффициентов.
для гарантии от ошибок ввода дублированных значений создаем уникальный индекс<коэффициент, удален/неудален> - ну вот теперь дальше тот сценарий который я вам написал выше...

Любая нормальная СУБД не даст вставить/изменить данные, нарушающие уникальный индекс. Или "проблема" - это корректно обработать ошибку, которую сгенерировала СУБД?

sp,

Если юзер не имеет права даже посмотреть запись, то с какого перепугу он сможет создать точно такую же? Хотя да, тут ваш начальник прав, спору нет - нагородить можно всякого.

На всякий случай напомню - я описывал только свой опыт и круг задач, с которыми сталкивался лично. И в самом начале подчеркивал, что есть наверняка и другие задачи, для которых могут быть условия или ограничения (в том числе архитектурные, а не диктуемые предметной областью), которые мне неизвестны, и которые требуют именно физически удалять данные с базы. Но изначальный вопросс как раз и был об опыте, не?

softwarerМиша не горячится и для разнообразия прав.

Красиво сформулировано, да. Спасибо за поднятое настроение