Вопрос ко всем разработчикам.
Используете ли вы имитацию удаления (то есть пометка записи, что она удалена)? Если да, то в каких случаях и почему. Если нет, то тоже почему.
P.S. Не стал делать тему опросом. Достаточно высказаться здесь.
"Мягкое" удаление записей. Хорошо это или плохо
В справочниках никакого удаления в принципе, перевод другое состояние. То же с документами. Если это считать таким "мягким" удалением - практически всегда.
Удаления - только внутрипрограммные (не по желанию пользователя, а согласно логике системы).
Если развить тему в сторону внедрения поддержки такой "фичи" в сервер (наподобие как это в bdf живёт) - я категорически против. Сервер ничего не знает о логике работы системы, а внезапное "появление" уже убитого объекта должно обрабатываться системой, а не сервером.
Удаления - только внутрипрограммные (не по желанию пользователя, а согласно логике системы).
Если развить тему в сторону внедрения поддержки такой "фичи" в сервер (наподобие как это в bdf живёт) - я категорически против. Сервер ничего не знает о логике работы системы, а внезапное "появление" уже убитого объекта должно обрабатываться системой, а не сервером.
Насчёт справочников уже сказали. Документы же вообще по жизни обладают небулевским статусом. Как минимум - подготовка, активный, закрытый, аннулированный. Удалять можно, в плане сиюминутного исправления текущих ошибок, но только в статусе "подготовка", впрочем как и редактировать (кроме форс-мажорных случаев). Главная проблема использования признака удаления - отношения m:n. Можно, но геморно. Посему таки в них удаление - рабочая операция, а для репликации используется лог. Отдельная тема - бухгалтерия, не в смысле настоящщая, а в смысле отдел по борьбе с налогами. Там порой проще и лучше снести все проводки за период и перепровести заново.
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Они нужны в джойнах по уже свершившемуся. Классика - снятая с производства продукция, продолжающая фигурировать в сводной отчётности и аналитике. Или почившая в бозе организация. А там признак удаления либо пофиг либо является просто атрибутом. А при работе со справочником для создания новых документов неживые записи фильтруются. Это в первом приближении. Есть ещё деятельность задним числом. И тут мы приходим к периодическим реквизитамCyberMax писал(а):Почему в справочниках "мягкое удаление"? Ведь эти данные нужны постоянно. Получается, что они постоянно выбираются с условием Deleted = 0, что скорость их выборки ничуть не прибавляет.
Хм. Одно дело - убрать ненужный вид продукции, а другое - пометить на удалить его. Для последнего есть две причины - возможность "оживления" и второе - чтобы сохранить ссылочную целостность. Кстати, в настоящее время для первого случая использую поле "HIDDEN".
Так вот, так ли необходимо это "оживление"? А вот насчет целостности надо подумать - может, есть вариант удалить сразу всю "ветку" (запись и ее мастера)... Просто не могу сходу вспомнить противопоказаний...
Так вот, так ли необходимо это "оживление"? А вот насчет целостности надо подумать - может, есть вариант удалить сразу всю "ветку" (запись и ее мастера)... Просто не могу сходу вспомнить противопоказаний...
Тогда скажи какие причины бывают именно на удалить не в "проектах" информационных объектов, а в действующих 
Я таких не знаю. Всё нужно для истории, разбора полётов между юзерами, восстановления каких-то хранимых агрегатов после искажений из-за ошибок кодеров и т.п. Есть варианты с логами на больших и плохо индексируемых по логике предметной области таблицах, для ускорения оперативной работы, но это не особо типичный случай в АСУП.
Я таких не знаю. Всё нужно для истории, разбора полётов между юзерами, восстановления каких-то хранимых агрегатов после искажений из-за ошибок кодеров и т.п. Есть варианты с логами на больших и плохо индексируемых по логике предметной области таблицах, для ускорения оперативной работы, но это не особо типичный случай в АСУП.Это две реально действующие базыMerlin писал(а):Тогда скажи какие причины бывают именно на удалить не в "проектах" информационных объектов, а в действующих
.Просто уже неделю обновляю код/метаданные самой первой своей БД и всплыл факт - операторы больше года не пользуются "оживлением" документов (в моем случае заявок). Это как бы понятно - удалил запись в справочнике/журнале - и все забыл о ней. С другой стороны, в 1С записи сначала помечаются, а затем удаляются. Но тогда надо делать поддержку поля Deleted... С другой стороны, на основании записей можно действительно делать анализ действий пользователей. С другой стороны, размер БД растет...
Короче, загрузился вариантами "За" и "Против". В инете ничего не нашел по данному вопросу, и решил у народа узнать. Если у всех "мягкое" удаление, то и у себя сделаю его во всех таблицах. Конечно, с возможностью окончательного удаления помеченных записей.
P.S. Вопрос этот, кстати, про проектирование БД. Только раздела здесь нет такого. Пришлось в ЧаВо создать...
-
Ivan_Pisarevsky
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Для этого можно и бэкап поднять, у меня к примеру для этого есть стопочка двд компактиков (никак чето до стримера не дорастем), на случай форс-мажора. Форс-мажор (тьфу-3х) слава богу давно не наступал, но бэкап иногда поднимал для того чтоб кое-кому особо шаловливому по шапке дать.Merlin писал(а):Всё нужно для истории, разбора полётов между юзерами
Вобщем раз бэкап все равно есть, можно им иногда и воспользоваться.
[Модератор: Иван, не забывай указывать, кого цитируешь]
Вот когда бэкапы за день даже в сжатом состоянии будут занимать несколько DVD, посмотрю на тебя. Отдельный шкаф - это хорошо, но очень неудобно. Да и развёртывать его час времени на незагруженном сервере. А вот по готовым процедурам пройтись, которые сразу нужную статистику поднимут - самое то.Ivan_Pisarevsky писал(а):Для этого можно и бэкап поднять, у меня к примеру для этого есть стопочка двд компактиков (никак чето до стримера не дорастем), на случай форс-мажора. Форс-мажор (тьфу-3х) слава богу давно не наступал, но бэкап иногда поднимал для того чтоб кое-кому особо шаловливому по шапке дать.
Вобщем раз бэкап все равно есть, можно им иногда и воспользоваться.
Объём базы существенно ограничивает возможности для сохранения всех данных, всё равно приходится со временем что-то чистить или перекидывать в отдельную, архивную базу.
Бэкапы базы что-ли? Давайте подсчитаем. Размер упакованного fbk (WinRAR'ом на макс. сжатии) ~ 10% от размера fbk. Размер бэкапа ~50% от fdb. Итого на DVD помещается база размером 4,5 Гб * 2 * 10 = 4,5 Г * 20 = 90 Гб. Базы таких размеров - это очень большое исключение. У тебя именно такая? Или ты прямо fbk на диск пишешь?WildSery писал(а):Вот когда бэкапы за день даже в сжатом состоянии будут занимать несколько DVD, посмотрю на тебя.
2 All. Давайте не будем отходить от темы - проблему логирования действий пользователей можно рассмотреть в отдельной теме, если кого-то она интересует.
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Давайте без оскорблений.Dimitry Sibiryakov писал(а):Вот как раз на эту задачу можно запрячь репликацию. Если приложить немного hands.drv и head.sys...
[модератор: давайте без подозрений. Где тут оскорбления?]
Репликация есть. Из оперативной в архивную и дальше в головное предприятие, т.е. ко мне.
Да, время потери сокращается до "время последнего бэкапа + данные репликации", но всё равно, даже час по понятиям нашего начальства - много. И я могу их понять.
2 модератор:
Признаю наличие чрезмерного воображения. Обычно оно не подводит, и я вижу что мне хотят сказать. Не в этом случае, очевидно
Последний раз редактировалось WildSery 17 июл 2006, 20:08, всего редактировалось 1 раз.
Почему же непонятно? Диалог свернул к вопросу "что лучше для восстановления данных - "мягкое" удаление или же удалять жёстко, а в случае нужны бэкап базы поднять, если "разборки" потребуются".kdv писал(а):непонятно - каким образом разговор про "мягкое удаление" и архивы перетек в плоскость восстановления после сбоя?