iBase.ru Forum

Вопрос ко всем разработчикам.
Используете ли вы имитацию удаления (то есть пометка записи, что она удалена)? Если да, то в каких случаях и почему. Если нет, то тоже почему.
P.S. Не стал делать тему опросом. Достаточно высказаться здесь.

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

В справочниках никакого удаления в принципе, перевод другое состояние. То же с документами. Если это считать таким "мягким" удалением - практически всегда.
Удаления - только внутрипрограммные (не по желанию пользователя, а согласно логике системы).

Если развить тему в сторону внедрения поддержки такой "фичи" в сервер (наподобие как это в bdf живёт) - я категорически против. Сервер ничего не знает о логике работы системы, а внезапное "появление" уже убитого объекта должно обрабатываться системой, а не сервером.

Насчёт справочников уже сказали. Документы же вообще по жизни обладают небулевским статусом. Как минимум - подготовка, активный, закрытый, аннулированный. Удалять можно, в плане сиюминутного исправления текущих ошибок, но только в статусе "подготовка", впрочем как и редактировать (кроме форс-мажорных случаев). Главная проблема использования признака удаления - отношения m:n. Можно, но геморно. Посему таки в них удаление - рабочая операция, а для репликации используется лог. Отдельная тема - бухгалтерия, не в смысле настоящщая, а в смысле отдел по борьбе с налогами. Там порой проще и лучше снести все проводки за период и перепровести заново.

Почему в справочниках "мягкое удаление"? Ведь эти данные нужны постоянно. Получается, что они постоянно выбираются с условием Deleted = 0, что скорость их выборки ничуть не прибавляет.

Выбираться они по идее должны с другим условием (скажем, по первым буквам) а Deleted идет уже пристяжным...

CyberMax писал(а):Почему в справочниках "мягкое удаление"? Ведь эти данные нужны постоянно. Получается, что они постоянно выбираются с условием Deleted = 0, что скорость их выборки ничуть не прибавляет.

Они нужны в джойнах по уже свершившемуся. Классика - снятая с производства продукция, продолжающая фигурировать в сводной отчётности и аналитике. Или почившая в бозе организация. А там признак удаления либо пофиг либо является просто атрибутом. А при работе со справочником для создания новых документов неживые записи фильтруются. Это в первом приближении. Есть ещё деятельность задним числом. И тут мы приходим к периодическим реквизитам

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

Тогда скажи какие причины бывают именно на удалить не в "проектах" информационных объектов, а в действующих Я таких не знаю. Всё нужно для истории, разбора полётов между юзерами, восстановления каких-то хранимых агрегатов после искажений из-за ошибок кодеров и т.п. Есть варианты с логами на больших и плохо индексируемых по логике предметной области таблицах, для ускорения оперативной работы, но это не особо типичный случай в АСУП.

Merlin писал(а):Тогда скажи какие причины бывают именно на удалить не в "проектах" информационных объектов, а в действующих

Это две реально действующие базы .
Просто уже неделю обновляю код/метаданные самой первой своей БД и всплыл факт - операторы больше года не пользуются "оживлением" документов (в моем случае заявок). Это как бы понятно - удалил запись в справочнике/журнале - и все забыл о ней. С другой стороны, в 1С записи сначала помечаются, а затем удаляются. Но тогда надо делать поддержку поля Deleted... С другой стороны, на основании записей можно действительно делать анализ действий пользователей. С другой стороны, размер БД растет...
Короче, загрузился вариантами "За" и "Против". В инете ничего не нашел по данному вопросу, и решил у народа узнать. Если у всех "мягкое" удаление, то и у себя сделаю его во всех таблицах. Конечно, с возможностью окончательного удаления помеченных записей.
P.S. Вопрос этот, кстати, про проектирование БД. Только раздела здесь нет такого. Пришлось в ЧаВо создать...

Merlin писал(а):Всё нужно для истории, разбора полётов между юзерами

Для этого можно и бэкап поднять, у меня к примеру для этого есть стопочка двд компактиков (никак чето до стримера не дорастем), на случай форс-мажора. Форс-мажор (тьфу-3х) слава богу давно не наступал, но бэкап иногда поднимал для того чтоб кое-кому особо шаловливому по шапке дать.

Вобщем раз бэкап все равно есть, можно им иногда и воспользоваться.

[Модератор: Иван, не забывай указывать, кого цитируешь]

Ivan_Pisarevsky писал(а):Для этого можно и бэкап поднять, у меня к примеру для этого есть стопочка двд компактиков (никак чето до стримера не дорастем), на случай форс-мажора. Форс-мажор (тьфу-3х) слава богу давно не наступал, но бэкап иногда поднимал для того чтоб кое-кому особо шаловливому по шапке дать.

Вобщем раз бэкап все равно есть, можно им иногда и воспользоваться.

Вот когда бэкапы за день даже в сжатом состоянии будут занимать несколько DVD, посмотрю на тебя. Отдельный шкаф - это хорошо, но очень неудобно. Да и развёртывать его час времени на незагруженном сервере. А вот по готовым процедурам пройтись, которые сразу нужную статистику поднимут - самое то.

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

WildSery писал(а):Вот когда бэкапы за день даже в сжатом состоянии будут занимать несколько DVD, посмотрю на тебя.

Бэкапы базы что-ли? Давайте подсчитаем. Размер упакованного fbk (WinRAR'ом на макс. сжатии) ~ 10% от размера fbk. Размер бэкапа ~50% от fdb. Итого на DVD помещается база размером 4,5 Гб * 2 * 10 = 4,5 Г * 20 = 90 Гб. Базы таких размеров - это очень большое исключение. У тебя именно такая? Или ты прямо fbk на диск пишешь?

2 All. Давайте не будем отходить от темы - проблему логирования действий пользователей можно рассмотреть в отдельной теме, если кого-то она интересует.

CyberMax писал(а):Бэкапы базы что-ли? Давайте подсчитаем...

Вы недопоняли меня. Бэкапы базы. При активном документообороте восстановление даже 4-5 часов потерянных данных накладно. А работа круглосуточная.

Вот как раз на эту задачу можно запрячь репликацию. Если приложить немного hands.drv и head.sys...

Все равно не пойму. Бэкапы базы, которые .fbk?

Dimitry Sibiryakov писал(а):Вот как раз на эту задачу можно запрячь репликацию. Если приложить немного hands.drv и head.sys...

Давайте без оскорблений.
[модератор: давайте без подозрений. Где тут оскорбления?]
Репликация есть. Из оперативной в архивную и дальше в головное предприятие, т.е. ко мне.
Да, время потери сокращается до "время последнего бэкапа + данные репликации", но всё равно, даже час по понятиям нашего начальства - много. И я могу их понять.

2 модератор:
Признаю наличие чрезмерного воображения. Обычно оно не подводит, и я вижу что мне хотят сказать. Не в этом случае, очевидно

непонятно - каким образом разговор про "мягкое удаление" и архивы перетек в плоскость восстановления после сбоя?

kdv писал(а):непонятно - каким образом разговор про "мягкое удаление" и архивы перетек в плоскость восстановления после сбоя?

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

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