Спасибо огромное за столь подробный комментарий! Я очень ценю ваше время, потраченное на ознакомление со статьей и формулирование советов. Постараюсь учесть все ваши рекомендации. Код с парсером обязательно опубликую в следующих статьях. Мне тоже очень интересно, до какой стадии разработки парсера я смогу дойти :)
Цель №1: помочь людям с быстрым поиском и выбором выгодного тарифа для их пользования.
Планирую по началу парсить раз в неделю, как парсинг настрою на стабильную работу, планирую парсить ежедневно. Если это плохая идея, напишите, пожалуйста, реалистичный разворот событий.
Да, действительно это так, планирую отлавливать ошибки и модернизировать парсер, другого решения пока не вижу.
Учту замечания, дополню, отредактирую статью. Парсер будет получать тарифы у провайдеров и проверять, существуют ли эти тарифы в базе данных. Если обнаруживаются какие-либо отличия в тарифе (например, отличается скорость или название тарифа), то данный тариф помечается как архивный, а триггер автоматически заполняет поле end_at, делая тариф неактивным.
Спасибо за помощь в выборе пэт-проекта, но я хотел бы раскрыть именно это направление. Почему вы считаете, что эта тема бесперспективна? Интересно ваше мнение
Ваш опыт безусловно превосходит мой, этой действительно небольшой путь к изучению SQL на начальных уровнях с созданием пет-проекта. Тащить логику в бд планировал не бездумно, а на сравнительных замерах производительности кода на Python и PostgreSQL , может быть проведённые опыты будут чем то полезны (не только мне). Вы правы, наверно с названием немного перегнул.
Да, вы правы! Я пересмотрю своё представление о данной архитектуре: уберу таблицу связей и сохраню связь в таблице тарифов. Таблицей фактов будет таблица тарифов, а таблицами измерений – города (географическое измерение) и провайдеры (бизнес-измерение, отражающее, кто предоставляет услугу).
Спасибо большое за замечание! Вы абсолютно правы, is_active - это антипаттерн при наличии временных меток. Лучший подход использовать только временные метки. Обязательно изменю это в своей структуре
Спасибо огромное за столь подробный комментарий! Я очень ценю ваше время, потраченное на ознакомление со статьей и формулирование советов. Постараюсь учесть все ваши рекомендации. Код с парсером обязательно опубликую в следующих статьях.
Мне тоже очень интересно, до какой стадии разработки парсера я смогу дойти :)
Атрибуты которые парсятся указал в таблице тарифов, сравнительный анализ буду производить в дальнейшем, покажу в следующих статьях.
Цель №1: помочь людям с быстрым поиском и выбором выгодного тарифа для их пользования.
Планирую по началу парсить раз в неделю, как парсинг настрою на стабильную работу, планирую парсить ежедневно. Если это плохая идея, напишите, пожалуйста, реалистичный разворот событий.
Да, действительно это так, планирую отлавливать ошибки и модернизировать парсер, другого решения пока не вижу.
Спасибо за хорошие вопросы!
Учту замечания, дополню, отредактирую статью. Парсер будет получать тарифы у провайдеров и проверять, существуют ли эти тарифы в базе данных. Если обнаруживаются какие-либо отличия в тарифе (например, отличается скорость или название тарифа), то данный тариф помечается как архивный, а триггер автоматически заполняет поле
end_at, делая тариф неактивным.Спасибо за помощь в выборе пэт-проекта, но я хотел бы раскрыть именно это направление. Почему вы считаете, что эта тема бесперспективна? Интересно ваше мнение
Я только учусь;) Спасибо за комментарий! В дальнейшем я постараюсь повышать качество статей, в том числе благодаря вашим комментариям!
Ваш опыт безусловно превосходит мой, этой действительно небольшой путь к изучению SQL на начальных уровнях с созданием пет-проекта. Тащить логику в бд планировал не бездумно, а на сравнительных замерах производительности кода на Python и PostgreSQL , может быть проведённые опыты будут чем то полезны (не только мне). Вы правы, наверно с названием немного перегнул.
Да, вы правы! Я пересмотрю своё представление о данной архитектуре: уберу таблицу связей и сохраню связь в таблице тарифов. Таблицей фактов будет таблица тарифов, а таблицами измерений – города (географическое измерение) и провайдеры (бизнес-измерение, отражающее, кто предоставляет услугу).
Спасибо большое за замечание! Вы абсолютно правы, is_active - это антипаттерн при наличии временных меток. Лучший подход использовать только временные метки. Обязательно изменю это в своей структуре