Схема БД MySQL для регистрации производительности PPC AD, изо дня в день - PullRequest
Новая
       22

Схема БД MySQL для регистрации производительности PPC AD, изо дня в день

0 голосов
/ 03 июня 2011

Я пытаюсь завершить перестройку рекламной системы для сайта. Конец отчетности / регистрации в новой модели PPC создает некоторые трудности, и я потерял голову для лучших идей. Данная таблица будет называться «отчеты» и будет содержать ad_id, показы, клики и CTR% для каждого объявления в системе, ежедневно в течение 1 скользящего года.

Простое решение выглядит так 

CREATE TABLE IF NOT EXISTS `reports` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `ad_id` int(11) NOT NULL,
  `impressions` int(11) NOT NULL,
  `clicks` int(11) NOT NULL DEFAULT '0',
  `ctr` float(6,3) NOT NULL DEFAULT '0.000',
  `report_date` date NOT NULL,
  PRIMARY KEY (`id`)
)

Проблема возникает, когда вы смотрите на дни недели. Я хочу иметь возможность собирать цифры для каждого рекламодателя и показывать отчеты изо дня в день У нас будет несколько рекламодателей с несколькими объявлениями для каждого. Наиболее очевидный (и нелепый) вариант - построить таблицу на каждый день года.

Если я использую столбец «report_date», моя таблица отчетов в конечном итоге превратится в беспорядок. Управление обновлениями для этих данных в этом случае будет включать общее: 

if there is no record for today - INSERT new record
else UPDATE existing record for today

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

Любая помощь приветствуется, спасибо!

1 Ответ

1 голос
/ 04 июня 2011

Звучит так, как будто вам нужен датамарт.Хранение исторической информации в транзакционной системе будет вызывать у вас постоянную головную боль.Запросы / обновление строк в вашей транзакционной системе будут очень медленными.Моя рекомендация оставить таблицу как минус report_Date.

Моя рекомендация - это не реляционная модель измерений.Создайте базу данных для отчетов и в этой базе данных используйте факт снимка, как показано ниже.Похоже, будут и другие интересные измерения.Это позволит пользователям видеть клики / ctr по URL или по дням.Ваш вход в гигантский факт основан на оптимизированных индексированных ключах.Google мерное моделирование для получения дополнительной информации.Объединение истории / отчетности / транзакции обычно приводит к плохому дизайну.Если вам нужна помощь о том, как заполнить этот комментарий.dimensional add model

...