ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Удаление записей с возможностью восстановления
15 сообщений из 15, страница 1 из 1
Удаление записей с возможностью восстановления
    #38761429
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
Добрый день!

В целом вопрос относится именно к проектированию, добавлю только то, что реальная база на которой планируется всё это сделать - PostgreSQL.

----------------------------------
Задача:
----------------------------------
Предположим у нас есть некая таблица objects и есть некая таблица users .

У objects есть внешний ключ на users : user_id .

Необходимо реализовать функционал "Удаление объектов с возможностью восстановления".

Например, зашел клиент на сайт, жмет кнопку "Удалить", а вместо нее появляется кнопка "Восстановить". Но, когда он перешел уже на другую страницу, то этой записи уже нет в списке объектов.

Но, зато у пользователя есть страница "История", в которой он видит все удаленные им объекты и так же имеет возможность их восстановить.
----------------------------------
Предварительное решение:
----------------------------------
Создать поле status в таблице objects и если он deleted, то значит запись удалена. Восстановление записи равносильно выставлению флажка status = regular.

Мне кажется есть более лучшие решения таких задач. Хотелось бы получить советы от уважаемых форумчан.
-----
Еще один гипотетический недостаток моего решения, на мой взгяд, в том, что если "удаленных" записей (status = deleted) будет слишком много , то они начнут мешать поиску по нормальным записям (из-за того что таблица будет большой ).
...
Рейтинг: 0 / 0
30.09.2014, 06:22
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761477
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Ну вариант "в лоб" с ведением таблицы истории недавно обсуждалось
Путешествия в прошлое
насколько оно более лучше решайте сами.
...
Рейтинг: 0 / 0
30.09.2014, 08:52
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761479
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
scymaks,
нет, более лучшего решения нет.
...
Рейтинг: 0 / 0
30.09.2014, 08:55
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761497
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
MasterZiv, понятно.

А как Вы считаете, стоит делать индекс на поле status?
...
Рейтинг: 0 / 0
30.09.2014, 09:21
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761528
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
scymaksЕще один гипотетический недостаток моего решения, на мой взгяд, в том, что если "удаленных" записей (status = deleted) будет слишком много , то они начнут мешать поиску по нормальным записям (из-за того что таблица будет большой ).

Не начнут, если у тебя будут хорошие критерии поиска.
Если критерии будут плохие, то даже без удалённых объектов ты будешь иметь проблемы.
И ты всегда можешь включить признак удаления в любой индекс, по которому ведётся поиск, и использовать его как доп. критерий поиска.
...
Рейтинг: 0 / 0
30.09.2014, 09:59
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761529
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
scymaksMasterZiv, понятно.

А как Вы считаете, стоит делать индекс на поле status?

Отдельно -- нет. А в совокупности с другими полями -- да.

Отдельно можно делать только если в СУБД есть технология пересечения разных индексов как Microsoft rush-more.
Но это бывает редко.
...
Рейтинг: 0 / 0
30.09.2014, 10:00
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761659
Фотография Станислав Клевцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Станислав Клевцов
Участник
scymaks,

У вас сейчас есть 2 справочника ...
Можно создать еще таблицу objects_users_link (уникальный индекс по полям object_id и user_id), в этой таблице добавить
поле status и создать таблицу objects_users_link_history (уникальный индекс по дате изменения \ добавления записи и objects_users_link_id ), в которой добавить тоже поле status

Нарисовать витрину, где таблица objects_users_link соединяется с objects_users_link_history по ключу objects_users_link_id и status из таблицы objects_users_link_history равен 1 (т.е. не удален). [ в таблице objects_users_link_history только для одной записи objects_users_link_id может быть статус 1]

Так вы сможете выводить всю историю изменений и менять для конкретной записи objects_users_link_id за нужную дату статус.
...
Рейтинг: 0 / 0
30.09.2014, 11:21
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761837
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
MasterZivscymaksЕще один гипотетический недостаток моего решения, на мой взгяд, в том, что если "удаленных" записей (status = deleted) будет слишком много , то они начнут мешать поиску по нормальным записям (из-за того что таблица будет большой ).

Не начнут, если у тебя будут хорошие критерии поиска.
Если критерии будут плохие, то даже без удалённых объектов ты будешь иметь проблемы.
И ты всегда можешь включить признак удаления в любой индекс, по которому ведётся поиск, и использовать его как доп. критерий поиска.


Пока что ожидается два типа запросов: достать объект(ы) по идентификатору / достать объекты по user_id
...
Рейтинг: 0 / 0
30.09.2014, 12:49
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38761930
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
scymaksMasterZivпропущено...


Не начнут, если у тебя будут хорошие критерии поиска.
Если критерии будут плохие, то даже без удалённых объектов ты будешь иметь проблемы.
И ты всегда можешь включить признак удаления в любой индекс, по которому ведётся поиск, и использовать его как доп. критерий поиска.


Пока что ожидается два типа запросов: достать объект(ы) по идентификатору / достать объекты по user_id

Ничего сложного не наблюдается.
Первое вообще по PK.
...
Рейтинг: 0 / 0
30.09.2014, 13:32
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38762222
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
MasterZiv,

Ну так теперь же всегда будет статус учавствовать.

Код: sql
1.
2.
3.
4.
5.
select * from objects where user_id = {} and status = regular
select * from objects where user_id = {}

select * from objects where id = {} and status = regular
select * from objects where id = {}



Вопрос, кстати, еще один интересует.

Стоит ли делать индексы на внешний ключ с условиями where?

Ну например, есть такие данные:
objects:
Код: sql
1.
2.
3.
4.
5.
6.
(id = 1, user_id = 1, ...)
(id = 2, user_id = 1, ...)
(id = 3, user_id = 1, ...)
(id = 4, user_id = 2, ...)
(id = 5, user_id = 2, ...)
(id = 6, user_id = 3, ...)



Стоит ли создавать индексы

Код: sql
1.
2.
3.
objects_by_user1: CREATE INDEX links__index_by_user1 ON links USING btree(_user_id) WHERE _user_id = 1;
objects_by_user2: CREATE INDEX links__index_by_user2 ON links USING btree(_user_id) WHERE _user_id = 2;
objects_by_user3: CREATE INDEX links__index_by_user3 ON links USING btree(_user_id) WHERE _user_id = 3;



...

?
...
Рейтинг: 0 / 0
30.09.2014, 15:42
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38762233
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
scymaksMasterZiv,

Ну так теперь же всегда будет статус учавствовать.

Код: sql
1.
2.
3.
4.
5.
select * from objects where user_id = {} and status = regular
select * from objects where user_id = {}

select * from objects where id = {} and status = regular
select * from objects where id = {}





Ну и добавь его в индексы на user_id (user_id, status).

В индекс по ID добавлять status бессмысленно, и проверять его бессмысленно -- только если ты не хочешь показать удалённый объект.
Если и хочешь, это без доп. затрат и так проверится, без добавления status в индекс по ID.
...
Рейтинг: 0 / 0
30.09.2014, 15:47
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38762237
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
scymaksСтоит ли делать индексы на внешний ключ с условиями where?

Ну например, есть такие данные:
objects:
Код: sql
1.
2.
3.
4.
5.
6.
(id = 1, user_id = 1, ...)
(id = 2, user_id = 1, ...)
(id = 3, user_id = 1, ...)
(id = 4, user_id = 2, ...)
(id = 5, user_id = 2, ...)
(id = 6, user_id = 3, ...)



Стоит ли создавать индексы

Код: sql
1.
2.
3.
objects_by_user1: CREATE INDEX links__index_by_user1 ON links USING btree(_user_id) WHERE _user_id = 1;
objects_by_user2: CREATE INDEX links__index_by_user2 ON links USING btree(_user_id) WHERE _user_id = 2;
objects_by_user3: CREATE INDEX links__index_by_user3 ON links USING btree(_user_id) WHERE _user_id = 3;



...

?


Зависит от того, какие запросы. Такие Индексы с WHERE по любому очень странны, и уж на всех пользователей их точно не нужно создавать. Либо на всех без where , либо на какого-то одного-двух юзеров.
...
Рейтинг: 0 / 0
30.09.2014, 15:50
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38762254
prog123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
prog123
Гость
MasterZivscymaksСтоит ли делать индексы на внешний ключ с условиями where?

Ну например, есть такие данные:
objects:
Код: sql
1.
2.
3.
4.
5.
6.
(id = 1, user_id = 1, ...)
(id = 2, user_id = 1, ...)
(id = 3, user_id = 1, ...)
(id = 4, user_id = 2, ...)
(id = 5, user_id = 2, ...)
(id = 6, user_id = 3, ...)



Стоит ли создавать индексы

Код: sql
1.
2.
3.
objects_by_user1: CREATE INDEX links__index_by_user1 ON links USING btree(_user_id) WHERE _user_id = 1;
objects_by_user2: CREATE INDEX links__index_by_user2 ON links USING btree(_user_id) WHERE _user_id = 2;
objects_by_user3: CREATE INDEX links__index_by_user3 ON links USING btree(_user_id) WHERE _user_id = 3;



...

?


Зависит от того, какие запросы. Такие Индексы с WHERE по любому очень странны, и уж на всех пользователей их точно не нужно создавать. Либо на всех без where , либо на какого-то одного-двух юзеров.

Удаление без where, это то, что должен усвоить каждый креативный разработчек:)
...
Рейтинг: 0 / 0
30.09.2014, 16:01
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38762454
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
scymaks Еще один гипотетический недостаток моего решения, на мой взгяд, в том, что если "удаленных" записей (status = deleted) будет слишком много, то они начнут мешать поиску по нормальным записям (из-за того что таблица будет большой)Люди не для того вводят данные чтобы их удалять. Иными словами очень вряд ли такое случится.
В любом случае (будя такое случится), можно добавить в регламент очистку старых удаленных данных с утаптыванием таблицы на физическом уровне.
У вашего статуса больше двух значений (regular, deleted)? Если только два то рекомендую обозвать поле типа is_deleted чтобы было меньше путаницы.
...
Рейтинг: 0 / 0
30.09.2014, 17:59
| Ответить | Цитировать | Написать  
Удаление записей с возможностью восстановления
    #38762505
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
scymaksВ целом вопрос относится именно к проектированию, добавлю только то, что реальная база на которой планируется всё это сделать - PostgreSQL
В том, что Вы написали, на логическом уровне Вы задействуете две сущности: ДЕЙСТВУЮЩИЕ_ОБЪЕКТЫ и УДАЛЁННЫЕ_ОБЪЕКТЫ. Вам нужно выбрать удобную реализацию на физическом уровне.

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

Основная альтернатива такому решению - использование отдельных таблиц для действующий и удалённых объектов. Это в общем вызывает двойной геморрой при сопровождении, а также усложняет операции удаления и восстановления, но обеспечивает более сильные гарантии в бизнес-логике - например, уже будет не так легко удалить объект, на который есть действующие ссылки. Зато если данные сильно связаны ссылками, такая схема становится подлинным кошмаром.
...
Рейтинг: 0 / 0
30.09.2014, 18:34
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Удаление записей с возможностью восстановления
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/search_topic.php?author=alingo&author_mode=last_posts&do_search=1]:
 0ms
get settings:
 8ms
get forum list:
 15ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 32ms
get topic data:
 14ms
get forum data:
 3ms
get page messages:
 64ms
get tp. blocked users:
 2ms
others: 438ms
total:  611ms
созд. / загр.: 611ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]