@eva2326

Всем привет!

Пытаюсь понять, как правильно проектировать базу данных.
И сейчас у меня такой вопрос: как поступать с записями, которые больше не актуальны, и могут быть удалены?

Как я поняла, есть две возможные стратегии:
1. Удаляем неактуальные записи, но тогда не используем индексы.
Это связанно с тем, что при удалении записи из таблицы, база пересоздает индексы, и это бъет по производительности.
Это действительно так уж ощутимо бъет по производительности?

2. Используем индексы, но тогда не удаляем записи, а лишь помечаем их в отдельном столбце как "удаленные".
Этот вариант используют даже несмотря на то, что в таблице может скапливаться много неактуальной информации.
Но ведь это же не рационально???


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

Но если их не удалять, а только помечать как удаленные, тогда очень быстро таблица вырастит до гигантских размеров, и при этом в ней 99% всех записей будет неактуальной информацией.

Получается, в моем случае предпочтительнее все таки первый вариант?

0

@D1973

eva2326, а теперь представьте ситуацию: Вы старательно удаляете записи и все бы хорошо, но... Вот кто-то накосячил, к примеру, с реквизитами, и теперь начальство хочет знать, кого казнить... А Вы не можете этого сказать, так как данные за этот прошедший период уже старательно удалены... Угадайте, кого казнить будут?

Лично мое мнение: данные в базе предназначены для хранения - вот и пусть хранятся. Максимум, что имеет смысл продумать - перенос неактуальных данных в какую-нибудь архивную таблицу, чтобы не перегружать таблицу рабочую...

0

@eva2326

Угадывать - это к гадалкам.
У программистов - логи, для разбора полетов, и бэкапы, для восстановления данных.

Ваше мнение не содержит ответа на мой вопрос.

Перенос данных в архивную таблицу подразумевает удаление данных из прежней таблицы.
А значит вопрос по первому пункту остается в силе.

0

@D1973

Правильно. А сколько времени займет бэкапирование текущего состояния + восстановление предыдущего состояния из бэкапа (а еще надо определить, на какой момент бэкап поднимать) по сравнению с выполнением одного запроса по "фиктивно удаленным" записям? Вас устраивает такой расход времени - удаляйте. Нет - храните.
А в чем вопрос-то? Индексируйте, если надо, архивную таблицу, а рабочая, в связи с незначительностью объема данных, обойдется без индекса.

0

@Аватар

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

Добавлено через 11 минут
add
из опыта - в задачах отгрузки и поставки данные накапливались годами, в определенный момент сохранялся бекап и текущее ПО и программно корректно чистилась база, оставляя движения и сопутствующее данные за последние 2-3 года. оставались частично и более ранние не закрытые данные. затрагивалось несколько десятков таблиц. индексы перестраивались

1

@eva2326

Эмммм....
Я думала, что при вставке индексы достраиваются, и это - относительно дешовая операция.
А при удалении происходит перестройка индексов, и это уже тяжелая операция.

А если при вставке индексы тоже перестраиваются, тогда получается, что обычная вставка - это тоже тяжелая операция.
Это как то странно...

Это если данные редко меняются, но по ним часто нужно делать поиск.

А если нужно постоянно добавлять/удалять данные, тогда получается, что лучше индексы вообще не использовать?
В таком случае от них будет больше вреда, чем пользы?

0

@iLinks

Как 3 вариант, помеченные записи, чистить разом, через какой-то период времени, если дата их создания < текущая дата - {какое-то кол-во дней/месяцев}.
Так, недавно помеченные на удаление данные можно будет еще просмотреть, что-то с ними сделать, а совсем старые грохнуть. Тут можно перед удалением делать бэкап еще.
Как дополнение 4 варианта с комбинацией того, что уже предложили. Помеченные на удаление данные, закидывать в архивную таблицу, разом, все что накопилось.

1

@eva2326

Я почитала разную интересную инфомацию на эту тему.
Если вкратце: sqlite использует для интексов B-деревья.
А это значит две вещи:

1. Индексы перестраиваются при любых операциях записи в базу.
При этом, вставка/удаление примерно одинаковые с точки зрения производительности.

2. Перестройка индексов на самом деле не такая уж медленная операция.
Не нужно бояться вносить изменения в данные.


А ещё, как я поняла, есть такая общая рекомендация: в первую очередь нужно отталкиваться от задачи.
Если по смыслу задачи данные больше не нужны, то и не нужно их держать/копить, только лишь из соображений оптимизации.
Ненужные записи можно просто удалять, не беспокоясь об индексах.

1