То, что записи не нужно физически удалять – это я согласен. А вот нужно ли иметь возможность восстановить логически удаленные записи?
Скажем, была группа товаров – "Ширпотреб" и содержалось там n-ное количество товаров. Допустим, что часть этих товаров входили и в другие группы (мн-ко-мн). Однажды начальник сказал: некрасиво, уберем эту группу. Начинаем убирать. Поперекидали товары в другие группы (не удалять же и их с группой). Потом другой говорит: да нормально, верните взад. Опять перекидывать? Наверное, было бы проще восстановить? Правда, отследить корректное восстановление всех связей при этом будет ой как непросто. Если вообще возможно.
Или, скажем, было решено переименовать "Ширпотреб" во "Всемпотреб". "Ширпотреб" ушел в историю и в списке актуальных групп не показывается. А потом кто-то решил, что нужен все-таки еще и "Ширпотреб". Соответственно, пользователь снова заводит "Ширпотреб" и кидает туда кучу новых товаров. Теперь если кому в голову придет, что в старом "Ширпотребе" было много нужных товаров, то восстановление этой записи приведет к очень большим хлопотам.
А ведь помимо начальского волеизъявления бывает еще что не ту группу удалили, не ту переименовали, да еще после этого успели перекидать и туда и оттуда и т.д.
Я понимаю, что в каждом конкретном случае надо отдельно решать, стоит проектировать возможность восстановления или нет, но, может, кто-нибудь поделится мыслями и примерами на эту тему?

2 softwarer
Спасибо!

2 guest_20040621
> Эта операция лишена смысла.
Почему?

> Хороший пример, как делать не нужно.
Так я и прошу привести примеры как нужно.

> Классификация - это вообще отдельная тема для обсуждения.
Согласен, так мы ее тут и не обсуждаем.

2 guest_20040621
> "Как нужно" не бывает.
Что-то Вы сами себе противоречите. То пишете: "Хороший пример, как делать не нужно", то - "Как нужно не бывает". Определитесь все-таки – бывает или нет?

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

> Тогда зачем Вы привели изменение классификации как пример?
Пожалуйста, можно без классификации. Просто свалены в кучу все товары. Часть из них удалили, как впоследствии выяснилось, ошибочно. Теперь их надо заново внести? Собственно, тут ведь идет речь о восстановлении данных вообще, безотносительно того, классифицированы они или нет.

2 BULK INSERT
> начальник оплачивает "восстановление ручками" как сверхурочку, за свой счет... или идет в жопу - обычное дело
Не, тут никто ничего не оплачивает, нужно самому все продумать и подстелить соломки везде, где это возможно.

2 BULK INSERT
> тут и добавить собственно нечего. если у вас логика удаления такова, что запись просто не отображается - это не > "логическое удаление" а просто сокрытие или фильтрация.
Ну да, раз мы "удалили" информацию - мы ее больше не показываем (кроме специальных запросов на историю данных).

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

2 guest_20040621
> Приемлемое решение - это когда по крайней мере грабли откровенно не торчат.
Ну вот Вы можете привести конкретный пример такого решения?

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

> Пример еще менее удачный, чем предыдущий. Поясните, пожалуйста, что это - "удалить товар"? Прекращение производства? Товары закончились на складе? Товары закончились у поставщика? У всех перечисленных ситуаций нет ничего общего с "удалить".
По-моему, принципиальной разницы нет. Ну, например, менеджер по продажам распорядился, что магазин больше не закупает водку "Похмелка" – ее ведь надо убрать из списка товаров на форме, где идет формирование заказа на склад?

И вот еще вопрос не по теме: существуют различные нормативные документы – ГОСТы, ТУ и т.д. Как общим словом называется аббревиатура (ГОСТ, ТУ) документа – тип?

2 Сергей Васкецов
Ну я и имею ввиду под "удалением" то, что Вы называете блокировкой – ведь физически запись не удаляется.

2 остальные
Да я согласен с guest'ом. Просто спрашивал о том, что делать, если, например, ошибочно завели (удалили) позицию товара. Думал, что запись остается как есть (физически в справочнике присутствует), а операции по ее отображению (выбору и т.д.) обусловлены флагом "удалена" ("блокирована", если хотите). Задумывал делать дополнительную таблицу по истории изменений этого статуса записи. И как, кстати, быть если введено неправильное НАЗВАНИЕ товара? Например, "Пахмелка"?

2 guest_20040621
> Любые данные, описывающие экземпляры сущностей, в отношении которых достоверно известно, что их > жизненный цикл закончен, могут быть помечены удаленными.
Спрошу Вас в Вашем стиле – а как мы будем оценивать степень достоверности? Имхо, это все условно. Нужно иметь возможность восстанавливать любую информацию, причины – см. мой первый пост (распоряжение второго начальника, отменяющее распоряжение первого, и оба – достоверны в контексте обсуждаемой проблемы).

2 guest_20040621
> Вы пытаетесь единообразно решать разные проблемы, хотя на самом деле и природа проблем, и методы их решения существенно различны.
Какие тут разные проблемы? Не понял.

> На самом деле любая база данных представляет собой некие собственные данные
Бывают еще ошибочно внесенные данные.

> Для внутренних данных все тоже просто: существует (или по крайней мере должен существовать) регламент всех процедур, связанных с получением, обработкой, хранением, обменом и пр. данных.
Т.е. Вы хотите сказать, что у Вас на каждый чих начальника существует регламент как, когда, где ему чихать? Вы, наверное, живете на Луне.

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

2 guest_20040621
>> на каждый чих начальника существует регламент
> Ничего, если я не буду отвечать на риторические вопросы?
Почему-то моя фраза была выдернута из контекста и смысл ее исказился. В оригинале было: " Т.е. Вы хотите сказать, что у Вас на каждый чих начальника существует регламент как, когда, где ему чихать?"
Поэтому это нисколько не риторический, а вполне конкретный вопрос.

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

2 Сергей Васкецов
Я согласен с Вашими словами, но Вы можете привести конкретный пример такого регламента? В вашей организации есть такой? Я думаю, что такие организации можно по пальцам пересчитать.

Давайте просто примем, что начальник чихает без регламента и подумаем, что нам теперь делать (в смысле как организовать базу).

Ну, с логическим удалением записей разобрались (большое спасибо guest_20040621 и всем остальным). Теперь другая проблема – что делать с изменениями в полях записи? Скажем, имеет запись несколько полей. Значение одного из них поменялось. Логично было бы где-н. зафиксировать этот факт. Смотрим "Журналирование изменений структуры БД и данных" (статья на SQL.RU). Много вариантов, я даже растерялся. Пока мне наиболее импонирует создание общей таблицы с полями:
- РК
- таблица где производится действие
- поле где производится действие
- ключ записи таблицы
- старое значение (а новое – в рабочей таблице)
- и т.д. (дата, юзер)
СУБД – Access. Каким типом сделать поле этой общей таблицы для записи старого значения – MEMO? Еще вопрос: если поднимать историю изменения данных какого-то поля какой-то записи, а там вместо понятных данных (скажем, наименование товара) только коды. Можно сделать простую подстановку из таблицы "Товары", но нет гарантии, что там не та же история (в смысле - меняли наименование товара). Не впадем ли мы в какой-н. бесконечный цикл обращений к таблице изменений?
Да, и еще, наверное, в каждую рабочую таблицу для каждого поля, данные в котором можно будет менять, можно было бы добавить дополнительное логическое, где при первом редактировании выставлять флаг. За подробностями – отсылать в общую таблицу изменений. Или не стоит так делать (вроде как избыточные данные), и при каждом перемещении от записи к записи и между полями бегать за справкой в общую таблицу изменений (нагрузка на сеть)?
Кто что скажет на эту тему?