|
|
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Хотелось бы узнать мнение на тему, кто как организует логическое удаление записей в БД (когда они удаляются на уровне пользователей, но физически продолжают присутствовать в БД) и какие в связи с этим преимущества и недостатки. Сейчас я вижу 2 варианта: 1. Пометка записи на удаление, т.е. введение поля статуса записи. 2. Введение в схему БД дополнительных таблиц для удаленных записей со структурой, совпадающей с оригинальной и перенос туда записей при удалении. По 1-му подходу я вижу следующие недостатки: некоторое увеличение времени запросов к данным, т.к. приходится отфильтровывать "удаленные" записи, а также усложнение в случае наличия уникальных ключей, когда значение ключа занимается удаленной записью и не может быть использовано в актуальной, т.е. ключ надо расширять на 2 поля. По 2-му подходу недостаток - в усложнении структуры данных и усложнении операции логического удаления (нужно помнить, что если у записи есть ссылки в дочерних таблицах, то их тоже нужно переносить в соответствующие зеркальные таблицы удаленных записей). Кто поделится мыслями или опытом по данной проблеме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 20:14 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
При наличии статусного поля время можно сделать практически неизменным с помощью партиционирования. Хотя не факт, что стоит так делать - имхо это зависит в первую очередь от ожидаемой пропорции актуальных и удаленных записей. Делая партиционирование по статусу, мы ускоряем select за счет торможения delete-а. Второй вариант - максимум, можно рассматривать как решение там, где нет партиционирования. Хотя все равно некрасиво. Логику работы с дочерними записями в любом случае придется тщательно прописывать. Даже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 22:08 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerДаже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:31 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_ softwarerДаже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view. Такой вариант у нас часто используется, единственная проблема не забывать делать проверку везде, где обрабатывается перечень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:35 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
EstetsТакой вариант у нас часто используется, единственная проблема не забывать делать проверку везде, где обрабатывается перечень. Ну как раз если организовать все запросы через фильтрующее представление, то эта проблема обходится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Ну как вариант Обратите внимание на основную фразу: логику обработки зависимостей в любом случае придется тщательно прописывать. Как именно - отдельный обсуждаемый вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 11:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerОбратите внимание на основную фразу: логику обработки зависимостей в любом случае придется тщательно прописывать. Как именно - отдельный обсуждаемый вопрос. Согласен, поэтому в том моем посте я цитировал только вашу фразу насчет реализации этой логики ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 11:48 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
А зачем хранить "удаленные" записи? Если хранить их без взаимосвязей, то разобраться в них будет просто невозможно. Если со связями, то вполне могут возникнуть взаимные коллизии. ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 15:18 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Удаленные данные хранятся для анализа и статистики (а также на случай возможного восстановления). Т.е. они могут быть недоступны обычным пользователям, которые будут считать, что данные удалены, но доступны привилегированным пользователям, которые смогут видеть всю историю и строить статистические отчеты. В том-то и дело, что при логическом удалении должны сохраняться все взаимосвязи. Хотелось бы услышать попдробнее насчет возможных взаимных коллизий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 15:41 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Хотелось бы услышать попдробнее насчет возможных взаимных коллизий. Была группа товара "Автомобили". Удалили все товары этой группы, а саму группу переименовали в "Лифчики". Можно так? Почему нет? Вот и увидит превилигированный пользователь в "Лифчиках" "ВАЗ-2110". Оно надо? А если подобная практика достаточно часта, то он там и "Гематоген" может увидеть и "черта лысого". Разбираться заморишся. И это самая простая (одноступенчатая) коллизия. Я помню, пробовал заниматься такой же вещью. За год работы ни разу этим не воспользовался, зато объем "логов" стал почти на порядок больше данных. Прибил, ибо нафик не надо. Может кроме случаев, оговоренных в законодательсве. Мусор надо выкидывать, ИМХО. А восстанавливать нужно из бэкапов, которые делать регулярно автоматом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 15:59 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
авторБыла группа товара "Автомобили". Удалили все товары этой группы, а саму группу переименовали в "Лифчики". Можно так? Почему нет? Вот и увидит превилигированный пользователь в "Лифчиках" "ВАЗ-2110". Оно надо? А если подобная практика достаточно часта, то он там и "Гематоген" может увидеть и "черта лысого". Разбираться заморишся. Ну это все решается на уровне бизнес-логики приложения. Переименовать можно и при наличии записей в группе, тогда ВАЗ в "Лифчиках" увидят все пользователи. А можно сделать так, что при удалении всех записей в группе автоматом удаляется и сама группа. Подразумевается все ж таки, что семантика групп не меняется, если говорить только о коллизиях такого рода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 16:11 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Ну это все решается на уровне бизнес-логики приложения. Если есть охота решать - решай. Только по объему это "решание" возможно будет сопоставимо с основным функционалом. Я бы все таки посоветовал честно ответить самому себе на вопрос - так ли нужны "анализ и статистика" по удаленным (читай ненужным) данным. Если действительно нужны - то желаю удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 16:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Ненужных данных в системе практически не бывает. Зато идиотов-пользователей - сколько угодно и еще больше. И как человек, который некоторое время регулярно разбирался с тем, что пользователи натворили в базе, могу сказать: любого прога, который попробует безвозвратно удалять любую запись, успевшую поучаствовать в бизнес-процессах, нужно срочно и серьезно лечить. Байка на тему. Некий пользователь пишет письмо в техподдержку - мол, не могу найти в системе приложение такое-то к договору такому-то. Девочка из поддержки ему терпеливо отвечает - мол, жмете сюда, вводите вот это, жмете сюда и получаете что хотите. Я не знаю, что ел на завтрак этот пользователь, но получив это письмо, он жмет куда указано, находит это приложение, удаляет его, после чего пишет второе письмо - мол, ни фига так не находится, ты не хочешь выполнять свои обязанности и помогать мне решить важную для бизнеса задачу, в общем, готовься увидеть небо в алмазах. Я в принципе допускаю, что данный конкретный случай был провокацией на тему "не прибьет ли эта девочка этого пользователя". Вот только таких не один и не два. Их почти за каждым десктопом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2006, 19:02 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view. Т.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же? Практика первого варианта есть в старом досовом клиппере. Там все что удалено помечается. Второй вариант похож на аудит (скорее всего триггерный). Ить тада можно еще записывать и кто и что не тока удалил, но и изменил. Я такое делал. Но там были просто "особые" данные изменение которых китайцы считали серьезным преступлением. Но всю БД так аудить накладновато будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2006, 20:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
vadiminfoТ.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же? Да, все же вариант с каскадной простановкой статусов при логическом удалении главной записи видится более предпочтительным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2006, 16:39 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerПри наличии статусного поля время можно сделать практически неизменным с помощью партиционирования. Хотя не факт, что стоит так делать - имхо это зависит в первую очередь от ожидаемой пропорции актуальных и удаленных записей. Делая партиционирование по статусу, мы ускоряем select за счет торможения delete-а. Как-то я реализовавыл этот вариант. Остался тестовый код, может кому пригодится: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:07 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_ vadiminfoТ.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же? Да, все же вариант с каскадной простановкой статусов при логическом удалении главной записи видится более предпочтительным. Если будешь реализовывать через VIEW, то изменение статуса (например атрибут DELETED as DATE_TIME is not NULL), то менять каскадно вообщем-то ничего и не придется. Пользователь просто не увидит этих данных, т.к. они связаны. А вообще-то системе можно разрешить и "удалять" записи. Вызывая в триггере PRE/POST-DELETE либо прекращение операции удаления, с изменением атрибута DELETED (PRE), либо дублирование записи (POST) и удаление оригинальной. Это зависит от выбранной СУБД. Правда обычно добавляют и атрибут DELETED_BY. Единственное с чем соглашусь, есть класс задач (очень маленький и специфичный) где это нужно. А в большенстве случаев можно прожить и без оной задумки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:31 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
nik_xЕсли будешь реализовывать через VIEW, то изменение статуса (например атрибут DELETED as DATE_TIME is not NULL), то менять каскадно вообщем-то ничего и не придется. Пользователь просто не увидит этих данных, т.к. они связаны. Я так понимаю, Вы имеете в виду следующее: если в мастер-таблице есть признак удаления и есть вьюха живых записей, то каскадного логического удаления дочерних записей не потребуется, поскольку пользователь просто "не дойдет" до этих записей по интерфейсу программы. Если так - не согласен. Причина этого очень проста: практически в любой нетривиальной системе существуют бизнес-функции, использующие позиции документа в отрыве от их заголовков. Скажем, отчеты наподобие оборотно-сальдовой ведомости вполне могут быть построены именно таким образом. Соответственно, в этом случае Ваш подход требует притягивания заголовков и проверки в них статуса записи везде, где используются позиции. Что есть неудобно для разработчика, неоптимально для сервера и прежде всего элементарно ненадежно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:58 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerЕсли так - не согласен. Причина этого очень проста: практически в любой нетривиальной системе существуют бизнес-функции, использующие позиции документа в отрыве от их заголовков. Скажем, отчеты наподобие оборотно-сальдовой ведомости вполне могут быть построены именно таким образом. Соответственно, в этом случае Ваш подход требует притягивания заголовков и проверки в них статуса записи везде, где используются позиции. Что есть неудобно для разработчика, неоптимально для сервера и прежде всего элементарно ненадежно. Угу а если физически удалять запись, то нужно следить чтоб везде удалялись хвосты иначе, см выше "в любой нетривиальной системе существуют бизнес-функции..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 15:05 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
- Да не согласен я. - С кем? С энгельсом или с Каутским? - С обоими, - ответил Шариков. - Это замечательно, клянусь богом. "Всех, кто скажет, что другая..." А что бы вы со своей стороны могли предложить? - Да что тут предлагать?.. А то пишут, пишут... Конгресс, немцы какие-то... Голова пухнет. Взять все, да и поделить... Булгаков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 15:05 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
EstetsУгу а если физически удалять запись, то нужно следить чтоб везде удалялись хвосты иначе, см выше "в любой нетривиальной системе существуют бизнес-функции..." Если физически удалять запись, то хвосты удалятся каскадом, если нормально схему спроектировать. To Ненавижу регистрацию Спасибо за пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 15:49 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
EstetsУгу а если физически удалять запись То во-первых, я выше аргументировал, почему так в большинстве случаев делать нельзя. Во-вторых, внешние ключи в этом случае уберегут от излишней забывчивости всех, кроме следующих Вашему дизайну без constraint-ов. В-третьих же таки Вы правы и именно это я и доказываю: к "хвосту" в любой реальной системе следует относиться тщательно и аккуратно, иначе будут проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 17:03 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerТо во-первых, я выше аргументировал, почему так в большинстве случаев делать нельзя. Во-вторых, внешние ключи в этом случае уберегут от излишней забывчивости всех, кроме следующих Вашему дизайну без constraint-ов. В-третьих же таки Вы правы и именно это я и доказываю: к "хвосту" в любой реальной системе следует относиться тщательно и аккуратно, иначе будут проблемы. Вы за Энгельса будете или за Каутского? ;) Согласен, лишних данных в системе не бывает. У нас физически удаляются только следующие данные: 1) Настройки (метаинформация) - поскольку доступ к ним имеет только администратор и ему и отвечать за внесенные исправления. 2) Агрегированная информация - например расситанные и сохраненные данные для отчетов, т.к. в случае необходимости можно эти данные расчитать еще раз. 3) Информация из внешних источников - опять-же если удаленная информация потребуется вновь, то ее можно будет восстановить. А по поводу "каскадного удаления" vs "каскадного проставления признака неактуальный", то если это делать триггерами затраты на программирование примерно одинаковые. Хотя замечу, что у нас нет каскадного обновления статусов записей, и вполне возможен вариант когда есть актуальный перечень, для неактуалной накладной. НО я ни разу не сталкивался с данной проблемой т.к. связанные перечни обрабатываются в связке с основным документом и проверяется "неудаленность" как позиции в перечне (так как она сама мола быть удалена) так и основного документа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 11:39 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Хотелось бы узнать мнение на тему, кто как организует логическое удаление записей в БД (когда они удаляются на уровне пользователей, но физически продолжают присутствовать в БД) и какие в связи с этим преимущества и недостатки. Сейчас я вижу 2 варианта: 1. Пометка записи на удаление, т.е. введение поля статуса записи. 2. Введение в схему БД дополнительных таблиц для удаленных записей со структурой, совпадающей с оригинальной и перенос туда записей при удалении. Могу предложить третий вариант, этот вариант использовался в банковсой системе которую я 2 года назад обслуживал, а сейчас я его реализовал в своей системе документооборота. Принцип вытекает из второго варианта, но только я не статус записи ввел а время действия документа Date_Begin и Date_End и состояние Пока запись актуальна Date_End = '01.01.2099:00:00:00' при удалении или любом изменении Date_End = Now все изменения делаются только процедурами, так легче и гибче можно отслеживать права. Процедура при любом изменении записи, делает ее копию с новым состоянием (включая все подчиненные таблицы) и проставляет даты начала конца. Этот подход позволяет видеть данные на любой момент времени, обеспечивает непротиворечивость отчетности со временем, ну и естественно всю историю изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 12:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
To nnov Спасибо за вариант. В принципе, такая подробная "историчность" и версионность данных не требуется. Однако поле с датой удаления - это нужная информация, тем более, что я думаю как раз на поле с датой удаления расширять уникальные ключи. Кроме того, думаю сделать отдельную таблицу дополнительной информации об удаленных объектах, где будут поля ID объекта Тип объекта Пользователь, удаливший запись Причина удаления Эта таблица не будет использоваться при работе обычных пользователей, она будет доступна только пользователям, имеющим доступ к удаленным записям. Таким образом, получается где-то комбинированный подход - с одной стороны для логического удаления используется статус, с другой стороны, есть отдельная таблица с дополнительной информацией об удаленных объектах. Хотелось бы узнать мнения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:19 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33625357&tid=1545242]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
176ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 509ms |

| 0 / 0 |
