 |
|
Модераторы: LSD |
 
|
|
Как правильно удалить данные? не удаляя их из БД 
| Ceiceron |
|
|||
 Шустрый  Профиль Группа: Участник Сообщений: 66 Регистрация: 2.8.2007 Где: Дубна Репутация: нет Всего: нет |
Задался таким вопросом. Возможно он больше архитектурного плана, но в практике работы с БД скорее всего встречается чаще. Пошерстил поиск, пришел к выводу, что конкретизировать вопрос не получается, соответственно строчу пост.
Итак. Есть некоторая БД, в ней регулярно создаются записи в таблицах, причем в некоторых таблицах может быть много записей и они наиболее часто опрашиваются (индексы на них есть, так что с производительностью вроде бы как проблем нет). Требуется удалить запись из такой толстой таблицы, но так что бы сама запись не удалялась, а становилась просто не видимой для слоя бизнес-логики приложения (фактически как-то маркируем запись, например есть поле is_deleted в таблице и в нем либо 0, либо 1 соответственно - фильтр). Это все хорошо, но система является открытой и в нее регулярно попадает приличное число мусора и табличка изрядно тяжелеет. Теперь вопрос: как разгрузить такую таблицу не сохраняя в ней удаляемые данные, но при этом все записи, помеченные как удаленные, должны быть доступны (обращение к ним крайне не частое, но есть)? |
|||
|
||||
Загрузка ...
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
Вариант таблица-архив, т.е. копия основной (плюс пара служебных полей).
Перенос записи в архив может быть 2 вариантов: 1. При добавлении в основную - добавляется в архив, при изменении основной - изменение архива при удалении из основной - ставится дата удаления. 2. При удалении из основной запись добавляется в архив. -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| Frees |
|
|||
 Эксперт Профиль Группа: Завсегдатай Сообщений: 2233 Регистрация: 2.12.2005 Где: Екатеринбург Репутация: 2 Всего: 54 |
в случае если все в одной таблице то все просто а если таблиц не 2 и не 3 а больше и все повязаны и каскады всякие то ИМХО луше флаг is_deleted -------------------- Кольцов Виктор Владимирович |
|||
|
||||
| Ceiceron |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 66 Регистрация: 2.8.2007 Где: Дубна Репутация: нет Всего: нет |
Вообще вопрос концептуальный. Пока решаю задачу через флаг is_deleted. Был опыт создания архивных таблиц, но это фактически иметь почти всю структуру БД в отдублированном виде. Есть мысль создать просто копию БД и в нее писать удаляемые данные, но тогда жутко загружается сам процесс удаления и встает бугром вопрос о том, что делать с таблицами-деревьями (т.е. имеющими ссылки сами на себя), при удалении не всегда можно потом восстановить из архивных таблиц правильные ссылки. В общем если подойти правильно к настройке и работе с СУБД, то огромная таблица не несет сильных проблем, просто периодически напускать на БД утилиту, которая проверит даты удаления и последнего обращения к записи (эти данные можно записывать в таблицу) и поубивает все записи с истекшим сроком годности.
|
|||
|
||||
| skyboy |
|
|||
|
неОпытный Профиль Группа: Модератор Сообщений: 9820 Регистрация: 18.5.2006 Где: Днепропетровск Репутация: 5 Всего: 260 |
есть идея: разделить хранилище по этому самому признаку is_deleted. к примеру, в mysql есть
patitioning - возможность по значению в некоем поле сохранять запись в один файл или другой. Таким образом, часто используемые неудаленные данные и редко используемые удаленные можно разнести на разные жесткие диски. к сожалению, невозможно указать разные engine(в таком случае, можно было бы для is_deleted вообще использовать движок Archive). подобный механизм есть и в mssql, и в postgresql, и в oracle Добавлено через 40 секунд mysql первый только потому, что я о нем первым подумал!  |
|||
|
||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
-------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| LSD |
|
|||
 Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Поле is_deleted плохо тем, что могут быть проблемы с уникальными ключами и другими констрейнами.
-------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
| Gluttton |
|
|||
 Начинающий Профиль Группа: Завсегдатай Сообщений: 1170 Регистрация: 28.8.2008 Где: Феодосия Репутация: 10 Всего: 54 |
Вот тут похожая тема.
А в первом посте ссылка на статью RSDN'a по теме топика... Возможно буте интересно ... -------------------- Слава Україні! |
|||
|
||||
| Ceiceron |
|
||||
|
Шустрый Профиль Группа: Участник Сообщений: 66 Регистрация: 2.8.2007 Где: Дубна Репутация: нет Всего: нет |
Какие проблемы тут могут быть? Целостность БД такое поле не нарушает, запросы будут проходить, другое дело, если не учитываешь значение данного поля: сам дурак. Gluttton, спасибо за ссылку, тема интересная и не только по поводу данной проблемы, почитаем.
разве IBExpert "садиться" на БД? С Fireberd давненько не работал. |
||||
|
|||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
IBExpert просто создает несколько объектов и в триггерах заполняет таблицы лога, далее предлагает GUI для просмотра этого лога. Такую GUI можно и самому сделать, если надо можно сюда выложить скрипт IBExpert'а. -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| DimW |
|
|||
 Эксперт Профиль Группа: Завсегдатай Сообщений: 1330 Регистрация: 24.2.2005 Где: Орёл Репутация: 2 Всего: 44 |
Ceiceron, на мой взгляд правильный и легко реализуемый вариант это:
плюсы: 1) сущность одна 2) данные по признаку разбиты ФИЗИЧЕСКИ |
|||
|
||||
| LSD |
|
|||
|
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Проблема не в этом поле, а в других полях. Допустим у тебя есть поле NAME, которое должно быть уникально. Вначале в таблице была запись со значением ABC, потом ее удалили. И получается ситуация, что пользователь не видит записи ABC, но и создать новую не может. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
| Frees |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 2233 Регистрация: 2.12.2005 Где: Екатеринбург Репутация: 2 Всего: 54 |
уникальность должна по 2 полям в таких случаях NAME и IS_DELETED -------------------- Кольцов Виктор Владимирович |
|||
|
||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
Если уж так хочется хранить признак удаления, то уж лучше 2 поля: 1. Date_Created 2. Date_Deleted но так же появляются проблемы с уникальностью, т.к. уникальный индекс на попадание в период сделать невозможно, только обычная проверка на существование записи. А такая проверка работает в контексте транзакции, и 2 человека в один момент времени смогут внести одинаковые записи. -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| Zloxa |
|
||||||||
 Чо? Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
тут на помощь придет fbi
правда отбираться по такому индексу "через альпы" и FK на него не накинешь. в общем случае секционирование наверно действительно не самый лучишй способ решения данной задачи.
Это очень даже себе частный случай, кода удаленные записи являют собой одну сущность с актуальными. т.е. равноценно должны участвовать в отборе, использоваться одинаковым образом бизнес логикой. В этом случае для секционирования наверно можно выбрать ключ и получше. Например неактуальная запись в справочнике товаров может означать что товар не должен быть использован впредь, однако в базе могут хранятся зарегестрированные ранее операци с этим товаром и логика обработки этих операций не должна различать удален товар или нет. Если же нам необходимо хранить удаленные данные не более чем для аудита, и они не используются бизнес логикой приложения, или же эта логика весьма отличается от логики использования актуальных данных, то это уже однозначно другая сущность, хотя имеет схожий набор атрибутов. Иная логика работы с этими данными может потребовать других индексов, и ограничений, потому использвание секционирования для такого случая наверняка окажется не рациональным.
Возникает вопрос. Если запись не используется бизнес логикой, зачем ее тогда хранить? Это сообщение отредактировал(а) Zloxa - 6.4.2010, 11:10 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка  |
||||||||
|
|||||||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.1343 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |