Записки программиста

Вчера, по дороге в офис, у меня возникли мысли почему бы не отойти от “стандартной” архитектуры системы управления рекламой, которую я обычно использую, и не создать что-то новенькое и интересное.

Под “стандартной” архитектурой я подразумеваю следующее… Есть интерфейсы, через которые происходит управление системой, есть база данных где храняться все данные и есть движок, который периодически забирает из базы данных необходимые данные, строит на основе этих данных некоторые планы по которым работает. Плюс движок, с заданной периодичностью, сбрасывает в базу данных счётчики по показам и кликам и сбрасывает в файлы логи всех запросов, на основании которых, с заданной периодичностью (ох уж эта заданная периодичность ) формируются отчёты.

А мысли возникли следующие… Интерфейсы напрямую работают с движком, который использует базу данных только для долговременного хранения данных на случай сбоев.

Из плюсов можно отметить следующее: все счётчики доступны в реальном времени, а не с “заданной периодичностью”, обновление данных происходят мгновенно, а не опять таки с “заданной периодичностью”.

Из минусов имеем существенное усложнение движка, необходимость реализации защищенного API по которому система будет управляться интерфейсами.

Решив что плюсы не перевешивают минусов, я принял решение делать крутилку по “стандартной” схеме…

Далее, одно из моих любимых занятий — проектирование баз данных, чем я вчера и занялся. Но приходилось себя постоянно сдерживать, чтобы не создать сразу огромную структуру данных, заложив туда кучу функционала. Буду наращивать функционал постепенно, создав сначала работающий продукт с минимумом функционала.

На данный момент структура базы данных выглядит следующим образом: db.sql. Имеем следующую структуру:

users — тут мы храним всех пользователей системы. Пока предусмотрено 2 роли пользователей: root и advertiser, — root у нас является администратором системы, advertiser представляет собой рекламодателя которому, наверняка, очень захочется следить за ходом своей кампании. Остальные поля в пояснениях не нуждаются, из названия можно понять зачем они нужны.

advertisers — рекламодатели вынесены в отдельную таблицу и связаны с таблицей users многие-ко-многим (таблица advertiser_users). Зачем это? У рекламодателя может быть несколько пользователей, желающих следить за ходом кампании, а потому, логично разделить их, а не давать один логин и пароль для всех. Да и потом, если рекламодатель что-то нахимичит, можно будет сказать какой пользователь это сделал, а не “у вас там кто-то что-то…”. Зачем многие-ко-многим, ведь можно было использовать один-ко-многим, просто добавив поле advertiser_id в таблицу users? Ну не хочется мне добавлять в таблицу пользователей лишние поля Да и потом, в перспетиве, если мы захотим реализовать интерфейс для рекламных агентств, нам такая схема облегчит жизнь (пока не думал как, но чувствую, что облегчит ).

advertiser_users — это связка рекламодателя с пользователями. Пояснения требует поле role. У рекламодателя пока предусмотрено две роли: user — простой пользователь, который может следить за ходом кампании, смотреть отчёты; root — администратор, который помимо прочего может создавать новых пользователей и управлять настройками кампаний, если такие будут.

geometries — таблица в которой будут хранится настройки форматов баннеров, или, давайте называть их не баннерами, а креативами. Коротко по полям: params — тут будут храниться поля которые нужно будет заполнить при создании креатива. Мне не хочется усложнять структуру, создавая под каждое возможное поле собственный столбец или добавлять таблицу с описанием типов полей и связывающую таблицу многое-ко-многим. Оно того не стоит. Второе поле требующее пояснения: template — это шаблон кода показа баннера, то что будет отдаваться в браузер пользователя.

channels — это каналы. Почему-то мне захотелось отойти от классических “сайтов” и сделать каналы, как это делают на западе. И в этом есть логика. Я не раз видел как создавалось несколько сайтов для одного реального сайта, чтобы разделить его логически на несколько разделов. Видел “сайты” код которых показывался сразу на группе реальных сайтов, и это тоже нормально. А потому у нас не будет сайтов, будут каналы. По полям: showed — количество показов креативов, showed_default — количество вызовов кодов (showed_default - showed = количество показов заглушек), clicked — количество кликов, статусов в нас три — активный канал, заблокированный канал (временно не работает) и удалённый. Тут сделаю маленькую ремарку. В нашей системе ничего удаляться не будет (кроме временных данных), а делается это для того чтобы при просмотре очётов у нас не появлялось пустых полей и мы не ломали голову о том, на каком из удалённых каналов были показы

creatives — это наши креативы. Поля: level — уровень креатива. Логика уровня следующая: сначала показываются все кретивы на уровне 0, потом на 1 и так далее. Зачем это надо? На 0 уровень ставятся коммерческие креативы, потом собственная реклама, потом заглушки и т.п. Думаю понятно? params — это значения параметров креатива которые заданы в одноимённом поле в таблице форматов, limit_* — это ограничения, думаю, по названиям полей понятно что они ограничивают. Ешё я думал добавить, как обычно, поле приоритета, которым можно было бы регулировать какие креативы должны показываться чаще, а какие реже, но передумал, потому как такое регулирование можно реализовать через ограничения показов. Любая коммерческая кампания ограничена по времени о показам (если это на статика), а значит ограничена по количеству показов в день, а значит по полю limit_shows_daily можно распределять приоритеты между креативами.

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

report_* — это таблицы в которых храняться отчёты. Думаю, по названиям таблиц и полей понятно что и где хранится

Оказывается писатель… Спасибо за внимание, продолжение следует

Tags: adboo, архитектура, база данных