|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serge Sapozhnikov 2:4635/4.34 10 Apr 2002 15:18:26
To : Vladimir Pavlikov
Subject : Каскадное удаление?
--------------------------------------------------------------------------------
02 Apr 87 15:19, you wrote to me:
>> Данные _уже_ попали в системы, пройдя некий контроль (физические
>> констрейнты, административные ограничения и т.д.). Попав в систему
>> можно сказать что это теперь информация. Если в последствии
>> оказалось что она неверна, то все равно гораздо логичнее не удалять
>> ее, а пометить как "неверная". Потому что представляет ценность хотя
>> бы для целей аудита или каких-то разборок.
VP> Разборки уже прошли, дальше что? Андрей Грачев привел простой пример,
VP> с неактуальным номером телефона. Если хочешь - еще один реальный
VP> случай, из жизни. Медсестра в поликлинике наложила на пациента
VP> электроды и сняла ЭКГ. Ее не смутила ни огромная надпись на красном
VP> фоне "DEMO MODE!!!", ни приставка Demo перед именем пациента (при этом
VP> запись идет не с датчиков, а из специальных тестовых файлов) - и
VP> записала фактически чужую ЭКГ (либо с иммитатора - не помню) на
VP> реального пациента. Можешь назвать ее слепой дурой, но это _факт_.
VP> Есть еще масса проблем, из-за которых ЭКГ м.б. несколько неверной -
VP> сильный внешний фон, плохой контакт электрода, проблема в самом
VP> электроде и т.д. А результат один - очень похожая на правду
VP> неверная ЭКГ. Фактически - тот самый двоичный мусор. Монитор покажет,
VP> что проблемный пациент обследован вовремя, и вообще все хорошо. А он
VP> через полгода помрет...
Ах, какая трагическая история!
Hасколько я понял, в некоторой системе хранятся ЭКГ? Hу так вот сохранить эту
"demo ЭКГ" нужно хотя бы для того, чтобы в последствии разобраться _почему_
пациенту поставили _такой_ диагноз.
С номером телефона совершенно также.
VP> Что до пометок о неверности - это
VP> дополнительный слой логики, которую нужно делать и обслуживать.
В большинстве случаев операцию удаления также нужно продумывать заранее.
Причем не только технические моменты, но и последствия отсутствия информации
бывшей в системе в будущем. Мой опыт говорит, что последнее, как правило,
слишком непредсказуемо и дорого обходится, несравнимо с затратами на реализацию
"дополнительного слоя логики".
VP> Этого
VP> зачастую слишком много (и совершенно ненужно) для оправдания неверных
VP> категорических утверждений :) --
Еще раз: я упомянул что имел ввиду "идеологическое" удаление. Моя личная
практика показывает что реальная система вполне может быть построена по принципу
"только накопления", а выглядит это так, что оператор delete в сервер вообще не
попадает. Плюсы от такого подхода запросто перевешивают "кажущиеся" недостатки.
Good luck, Serge
p.s.
Hасчет "зачастую" - я не имел ввиду "системки" у которых база аж 10-15 таблиц
и оператор, решив, что данные неверны имеет право удалить(!!!) и удаляет (!)
запись из таблицы. А с перепою может решить что все вчерашние данные тоже
неверны (ну и удалить безвозвратно).
--- [frogbot@ukr.net] [ICQ #11038130]
* Origin: DM4 (2:4635/4.34)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
