Как лучше хранить и объединять ежедневные, еженедельные, ежемесячные посещения для быстрого поиска?

Question

Я использую SQL Server 2008 и ColdFusion 9.

Мне нужно авторизоваться на моем сайте. Это будет для пользователей, которые вошли в систему. Мне нужно иметь возможность узнать, сколько раз они вошли в систему на этой неделе, в этом году, а также сколько дней подряд, очень похоже на то, как это делает StackExchange. Я хочу иметь возможность показывать календарь на любой месяц и отображать дни, которые посетитель посетил.

Я не уверен, что лучше всего хранить эти данные или извлекать их. Моя первоначальная мысль - создать ежедневную или еженедельную таблицу, в которую будут записываться каждое попадание каждого пользователя. Я бы сохранил идентификатор пользователя и метку времени следующим образом.

TABLE_VISITS_LAST_SEVEN_DAYS
UserID     VistitDateTime
101        2012-10-06 01:23:00
101        2012-10-06 01:24:00
101        2012-10-07 01:25:00
102        2012-10-07 01:23:00
102        2012-10-07 01:24:00
102        2012-10-07 01:25:00

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

TABLE_VISITS_ALL_TIME
UserID     VistitDate
101        2012-10-06
101        2012-10-07
102        2012-10-07

Эти данные будут легко запрашивать и не будут хранить ненужные данные. У меня были бы все данные, необходимые для определения того, как часто пользователь посещает мой сайт без особых усилий.

Это хороший план? Есть ли более простой или лучший способ? В моем плане зияющая дыра? Идеи будут оценены.

Answer 1

Я не понимаю необходимости двух таблиц.Второй - просто дедуплицированная версия первого;любые агрегированные запросы, которые вы делаете, все равно должны будут выполнять те же операции сканирования индекса, но только для таблицы немного меньшего размера.

Лично я думаю, что было бы более разумно, если бы вы создали свою первую таблицу, но поместили уникальный индекс в userid и часть гггг-мм-дд в visitdatetime (хотя visitdate теперь может быть более подходящим).Если у вас есть повторяющаяся запись, поймайте исключение и проигнорируйте его.

Тогда ваша первая таблица станет вашей второй по определению, и вам не нужно будет выполнять дополнительную работу в фоновом режиме.

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

Answer 2

Вы можете изменить объявление столбца VisitDateTime в TABLE_VISITS_LAST_SEVEN_DAYS на VisitDate as Date, а затем регистрировать каждое посещение таким образом:

INSERT INTO TABLE_VISITS_LAST_SEVEN_DAYS 
SELECT @UserID, @VisitDate
WHERE NOT EXISTS (
  SELECT 1 FROM TABLE_VISITS_LAST_SEVEN_DAYS (NOLOCK)
  WHERE UserID=@UserID AND VisitDate=@VisitDate
)

(@ VisitDate - переменная типа Date)

Answer 3

Почему бы просто не хранить каждое посещение, и если вам нужна ежедневная / еженедельная / какая-либо статистика, создайте запрос, который агрегирует по мере необходимости? Все зависит от того, сколько посещений вы ожидаете, и за какой период времени вы хотите сохранить статистику.

Edit:

Звучит так, будто вы предполагаете, что плохо спроектировать это просто Пока у меня быстрый сервер. Это верно?

Я совсем не это говорю. Ваше первое решение не плохое решение. Ваше второе решение не "лучше". Во всяком случае, это несколько денормализовано.

Нет лучшего способа сделать то, что вы описали. Существует несколько возможных решений, некоторые из которых могут быть адекватными вашим потребностям, а некоторые - нет.

1. Если вас интересует статистика, например, как часто отдельные пользователи посещают ваш сайт и сколько раз в день и когда, ваша первая таблица говорит вам об этом. Это связано с некоторыми дополнительными издержками при выполнении агрегации.
2. Если все, что вас когда-либо волнует, это то, посетил ли пользователь ваш сайт в определенный день, почему бы не сохранить только эту информацию? Вставьте одну строку в первый визит пользователя в этот день и не делайте этого до завтра.

Слишком много дополнительных затрат на запись одной строки за посещение будет зависеть от вашего конкретного применения. Небольшой сайт, который получает несколько тысяч посещений в месяц, - это не то же самое, что огромный сайт, такой как Amazon.

Кроме того, есть несколько способов сделать даже первое решение. Как настроены индексы и т. Д. Почему бы просто не сделать это и посмотреть, работает ли он? Создайте таблицу, вставьте то, что вы считаете типичным объемом данных, и попробуйте. Если он недостаточно эффективен, подумайте о других агрегирующих таблицах, ночных заданиях и т. П.

... преждевременная оптимизация - корень всего зла. - Дональд Кнут