Comments 22
я хотел бы осветить одну из "болей" абонентов - «архивные» тарифы. Абоненты годами сидят на устаревших и дорогих тарифах, не зная, что в их же доме уже давно доступны более выгодные предложения от конкурентов.
Что? Я не помню ни дня, что бы архивный тариф опсоса (а я с ними со времен nokia 3310) был хуже по деньгам для клиента... единственное исключение, временные бонусы за переход между провайдерами или покупка симки.
Пару раз я повелся и менял тариф на предлагаемый опсосом
(больше, лучше, всего за +20р), и оба раза меня 'качественно обманывали',.. из последних помню теле2 за апгрейдил мой архив, добавив плюшек но удалив минимальный пакет sms (тогда все опсосы их предлагали, это замылило глаз и не увидел в описании этого), а так как отсылка sms (десятки в месяц и опсос это прекрасно понимал) мне все еще нужна была, в итоге мне приходилось до 100р докидывать к абонентке именно из-за них, а назад никак.
Но в любом случае, каким бы плохим не был когда то сейчас уже архивный тариф, он все еще в разы дешевле любого доступного тарифа (есть 100р 'интернет вещей', но пока мобильный интернет не доломан, на него переходить не спешу).
Единственные, кому архивные тарифы мешают - это сами операторы сотовой связи.
p.s. как вы описываете тариф и главное как их сравниваете?
Абоненты годами сидят на устаревших и дорогих тарифах, не зная, что в их же доме уже давно доступны более выгодные предложения от конкурентов.
То ли плакать, то ли смеяться. Я знаю две возможности удешевить использование мобильной связи:
индивидуальное предложение, при этом всё зависит от оператора;
сменить оператора;
А буковки про более дешёвые тарифы - это не просто эффективно-менеджерский рекламно-маркетоложеский поток букв без подачи мысли, это прямое введение в заблуждение клиентов, что является нарушением закона.
DDL на создание 4х таблиц, гордо названный архитектурой - вот текущий уровень статей на хабре(
По технической части же - всё совсем грустно. Нет расширенного, хотя бы словесного, описания задачи, которая решается:
какие данные будут храниться для каждой из сущностей - тарифы, провайдеры, населённые пункты?
какую информацию будет возвращать ваше ПО?
в каком виде будет возвращать?
И т.д., и т.п.
Соответственно, нет полной структуры таблиц, что вызывает серьёзное удивление. Равно, как и кода, который будет создавать эти таблицы.
Зачем триггер? Вы отправляете запрос провайдеру, который возвращает информацию о том, что тариф переведён в архив, соответственно, ваше ПО должно просто обновить соответствующую информацию в БД. безо всяких триггеров.
Резюме. Материал не тянет даже на экзаменационный вопрос из курса проектирования баз данных для подготовки инженеров профильных специальностей, не говоря уже о чём-то более объёмном, начиная с лабораторных работ.
Учту замечания, дополню, отредактирую статью. Парсер будет получать тарифы у провайдеров и проверять, существуют ли эти тарифы в базе данных. Если обнаруживаются какие-либо отличия в тарифе (например, отличается скорость или название тарифа), то данный тариф помечается как архивный, а триггер автоматически заполняет поле end_at, делая тариф неактивным.
Уровень статьи я считаю начальный.Интересно и познавательно. Селиниум закрывает все проблемы парсинга , помню когда-то давно хардкодил при парсинге эх... было время 😅
В реальных проектах как-то не модно стало держать хоть какую-то логику в БД.
Я как-то реализовывал пилотный проект по трекингу активности неких объектов. В БД из mqtt попадал вектор ускорения с акселерометра, прицепленного к объекту, раз в секунду. Некая статистика считалась по месячному временному окну. В общем я сделал все это джобом и парой тройкой хранимок. Нагенерил сколько-то лямов измерений и считалось это все в БД не более секунды.
Так вот, команда, которая из моего пилота делала прод, все это выкинула и перенесла рассчёт на бэкэнд, гоняя миллионы неаггрегированных записей из БД на бэк.
У меня есть и другие примеры для моего замечания. А вы наоборот зачем-то хотите тащить логику в БД, причём в вашем случае никаких оправданий про эффективность нет. Признайтесь честно, вы просто изучаете SQL и постарались придумать какой-то пет-проект под это. Я не знаю ни одного DBA, который бы назвал четыре связанных таблицы с несколькими тысячами записей в перспективе - проектированием архитектуры.
Ваш опыт безусловно превосходит мой, этой действительно небольшой путь к изучению SQL на начальных уровнях с созданием пет-проекта. Тащить логику в бд планировал не бездумно, а на сравнительных замерах производительности кода на Python и PostgreSQL , может быть проведённые опыты будут чем то полезны (не только мне). Вы правы, наверно с названием немного перегнул.
Питон - скриптовый универсальный язык с низкой производительностью (иногда кроме гуру, которые используют его для быстрого прототипирования)
SQL - Язык запросов к СУБД, где postgres одна из худших реализацией, если сравнивать с Mssql и Oracle
Довольно трудно будет найти предметную область для сравнения. Но в любом случае там должно быть много данных.
И опыты не будут никому полезны. Поскольку в проде принято использовать язык под задачу, а не наоборот.
Это не схема «Звезда». dimension - хранят не измерения, а размерности. Таблица «город-провайдер» это не таблица «фактов», а таблица «пересечений».
Да, вы правы! Я пересмотрю своё представление о данной архитектуре: уберу таблицу связей и сохраню связь в таблице тарифов. Таблицей фактов будет таблица тарифов, а таблицами измерений – города (географическое измерение) и провайдеры (бизнес-измерение, отражающее, кто предоставляет услугу).
Это ещё более неправильно. Зачем вы применяете термины, смысл которых лежит в другой области (например в OLAP), не понимая его и подстраиваетесь под них в своей простой реляционной БД? Делайте что хотели, смысл не в правильных терминах, а в правильной работе проекта, согласно замыслу.
(а лучше выберите другую тему для пет-проекта, эта бесперспективна) могу подсказать пару тем с действительно большими данными.
Спасибо за помощь в выборе пэт-проекта, но я хотел бы раскрыть именно это направление. Почему вы считаете, что эта тема бесперспективна? Интересно ваше мнение
Главным образом вам уже выше объяснили, что не бывает новых тарифов выгоднее архивных.
Потом ЦА вашего приложения всегда в курсе о тарифах и хоть раз в полгода заглядывает на сайт провайдера.
Например у меня 4 прова и не было повода менять тариф никогда от 5 до 10 лет. Я могу перескочить с 300мбит до 1гб временно, по-надобности, и через месяц вернуться обратно на 300. Мне для этого справочник не нужен. Думаю, что у айтишников с одним провайдером все ещё проще
Зачем вам is_active, если есть nullable end_at?
В крайнем случае можно сделать generated column, хотя булевые поля вместо единого state поля все равно антипаттерн.
А для чего всё это затевается? Зачем парсить? Чтобы что?
В современных реалиях тарифы у провайдеров могут меняться в любой момент времени, могут меняться только по отдельным городам. Ты не будешь же каждый день парсить все города?
Кроме того, на сайтах может постоянно меняться карточка самих тарифов - добавят новую строку и твой парсер поломается. И ты каждый раз будешь его исправлять?
Цель №1: помочь людям с быстрым поиском и выбором выгодного тарифа для их пользования.
Планирую по началу парсить раз в неделю, как парсинг настрою на стабильную работу, планирую парсить ежедневно. Если это плохая идея, напишите, пожалуйста, реалистичный разворот событий.
Да, действительно это так, планирую отлавливать ошибки и модернизировать парсер, другого решения пока не вижу.
Спасибо за хорошие вопросы!
Парсинг тарифов интернета и ТВ: Архитектура БД и бэкенд на SQL