Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Удаление записей с возможностью восстановления / 15 сообщений из 15, страница 1 из 1
30.09.2014, 06:22
    #38761429
scymaks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей с возможностью восстановления
Добрый день!

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

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

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

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

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

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

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

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

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

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

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

Отдельно можно делать только если в СУБД есть технология пересечения разных индексов как Microsoft rush-more.
Но это бывает редко.
...
Рейтинг: 0 / 0
30.09.2014, 11:21
    #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, 12:49
    #38761837
scymaks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Удаление записей с возможностью восстановления
MasterZivscymaksЕще один гипотетический недостаток моего решения, на мой взгяд, в том, что если "удаленных" записей (status = deleted) будет слишком много , то они начнут мешать поиску по нормальным записям (из-за того что таблица будет большой ).

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


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


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


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

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

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

Основная альтернатива такому решению - использование отдельных таблиц для действующий и удалённых объектов. Это в общем вызывает двойной геморрой при сопровождении, а также усложняет операции удаления и восстановления, но обеспечивает более сильные гарантии в бизнес-логике - например, уже будет не так легко удалить объект, на который есть действующие ссылки. Зато если данные сильно связаны ссылками, такая схема становится подлинным кошмаром.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Удаление записей с возможностью восстановления / 15 сообщений из 15, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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