Как автоматически переносить записи, старше определенного значения, в архив?
Доброго дня, уважаемые.
Подскажите, как реализуют автоматическое перемещение записей, старше определенного времени, в архив?
Для наглядности (хотя итак всё очевидно): есть 10 записей. 9 из них были созданы вчера, 1 позавчера. Все, что timezone.now() - datetime_publish > 2 дней убираем в архив.
И еще, как этот архив реализуют? Доп. полем в общей таблице или же отдельной таблицей?
Pavel Denisov: Переместить в архив - однозначно отметить, что запись перемещена в архив.
Типичный новостник: Новость, опубликованная более, условно, 30 дней переносится в архив и отныне недоступна по старому url-у (news.ru/sports/news_id), а доступна по url-у (news.ru/archive/news_id).
Со стороны url-ов понятно, что нужно просто исключить эту новость из одной выборки и добавить в другую. Но как правильно всё организовать с другой стороны?
Будет ли эта запись, будучи архивной иметь True в поле Archive или же будет удалена из основной таблицы с новостями и добавлена в таблицу Archive? Вот, что хочу узнать.
Как-то так. Андрей Буров Предлагает воспользоваться "перегородками" в таблицах. Я не особо пока понял что это, куда это и как это. На первый взгляд, выглядит интересно, но сложно.
Допустим, решится проблема архитектурного плана, что делать с автоматизацией этого процесса? В той же статье (https://www.postgresql.org/docs/9.5/static/ddl-par... в конце написано что-то про функции-триггеры, но это однозначно сложно (для меня), хочется что-то более простое (если нет такового, то что ж поделаешь).
Андрей Буров: Вот и хочу узнать, как это правильно делается. Понятно, что крон всемогущ в вопросах подобных, но, вдруг, существуют более правильные подходы\решения.
Очень глупая затея. Только если у вас не закрытый новостной ресурс с доступом по платной подписке. Всё решается тупо пагинацией(постраничному выводу). Выводи на страницу последние 10-20 новостей, сортируя их по дате (сверху новые). В итоге все старые просто будут уходить вниз. Ну а менять урл это верх глупости. А если новость попала в индекс поисковой системы, если новость начали тиражировать другие ресурсы, социалки, форумы? То люди через N дней придя по ссылке, получат 404?
Вы наверно только пришли в веб программирование. Это какое-то маниакальное стремление новичков, чистить базу или удалять(прятать) старое. 100 - 1000 и даже 1 000 000 записей это не проблема для БД даже на шаред хостингах. Но новички часто трясутся из-за 1000.
Syschel: Мой преподаватель часто говорил примерно следующее:"Представьте, что записей у Вас очень много. Сколько это "очень много"? Представляйте 1 000 000, мало? Представляйте 1 000 000 000. Старайтесь делать так, что бы и на "очень много" работало более-менее оптимально".
Это какое-то маниакальное стремление новичков, чистить базу или удалять(прятать) старое.
- глупые новички, любят всё оптимизировать и избегать говна в коде и архитектуре. Бесят такие, ну.
Всё решается тупо пагинацией(постраничному выводу). Выводи на страницу последние 10-20 новостей, сортируя их по дате (сверху новые).
- рука->лицо
Написали по делу лишь два предложения:
А если новость попала в индекс поисковой системы, если новость начали тиражировать другие ресурсы, социалки, форумы? То люди через N дней придя по ссылке, получат 404?
- всё, остальное выбросить к чертям, как информационный мусор, пропитанный оскорбительными тонами. Вы крайне бестактны.
Pavel Denisov: Спасибо за мнение и советы! Убрал поле Archive, делаю фильтрацию на уровне SQL. Урл, действительно, менять смысла нет.
Если требуется отметка о том, что Ваши советы стали решением вопроса, то, пожалуйста, оформите ответ на данный вопрос. С удовольствием отмечу решением.
