2013-05-06 4 views
0

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

  • Добавить новые пользователи
  • Удаление пользователя
  • Разрешает пользователю
  • Отключить пользователя

А также пусть администратор выбирает период времени, а затем показывает, какие пользователи:

  • Доступен в системе в тот период
  • Enabled
  • Выключено

Результат должен быть для этого точного периода времени.

Примечание: Пользователь может быть включен или отключен несколько раз, и мне нужно отслеживать каждое изменение. Таким образом, если пользователь отключен между 1 марта и 2 апреля, он не должен появляться в результатах, если администратор запрашивает период времени с 1 марта по 2 апреля, но он должен быть включен в результаты, если запрос администратора любой другой период времени.

Кроме того, сложная часть состоит в том, чтобы содержать user, который был добавлен, удален, включен или отключен до периода, который запрашивает администратор.

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

Также я предпочитаю делать все в одном MySQL Query, однако комбинация/взаимодействие с PHP также хорошо.

+1

И вопрос ...? Methinks смотрят на медленно меняющиеся размеры и возвращаются: http://en.wikipedia.org/wiki/Slowly_changing_dimension –

+0

@Denis благодарит за ввод, я читаю это прямо сейчас ...:) – Mahdi

+0

@Denis Еще раз спасибо, это было действительно полезно. Я все еще не реализовал решение, но у меня появилась идея. Повторите отправку комментария в качестве ответа, чтобы я мог выбрать его как принятый ответ. Я уверен, что это может помочь и другим людям! :) – Mahdi

ответ

1

За комментарии, смотрите в медленно изменяющихся Размеры:

http://en.wikipedia.org/wiki/Slowly_changing_dimension

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

Придумайте основной, как обычный стол с дополнительной оборот (для REVISION_ID) поле:

id, rev, field1, field2 

оборот является внешним ключом к таблице пересмотров:

id, rev, field1, field2, start_date, end_date 

И если вы когда-либо использовать Postgres для его реализации, я бы посоветовал изучить тип tsrange вместо двух отдельных типов start_date и end_date.

Таблица основных таблиц и таблиц истории делает «обычные» запросы более удобными и удобными для индексирования.

+0

Спасибо, было очень приятно узнать об этом. Мне показалось, что я столкнулся с какой-то причудливой проблемой, которая мне нужна, чтобы, наконец, реорганизовать мою структуру, однако я извлек из этого хорошие вещи. Также спасибо за «tsrange», поскольку я также работаю с геоданными, я мог бы, наконец, перейти к Postgres, так как кажется, что это лучше, чем MySQL в некоторых (много?) Ситуациях. :) – Mahdi

+0

Сделайте все. :-) –

Смежные вопросы