Количество записей для различных пользовательских представлений - PullRequest
Новая
       6

Количество записей для различных пользовательских представлений

0 голосов
/ 05 января 2012

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

Пример: 

  All Records View(3): {criteria : none}
   Name |email       |age  
   John |john@foo.com| 23
   Ann  |ann@foo.com | 20
   Jack |jack@foo.com| 13


  Kids View(1): {criteria : age<15}
   Name |email       |age  
   Jack |jack@foo.com| 13

  Foo Kids View(1): {criteria : age<15 and email contains('foo.com')}
   Name |email       |age  
   Jack |jack@foo.com| 13

Как указано в вышеприведенном примере, в зависимости от критериев необходимо рассчитать количество просмотров для каждого просмотра. Подсчет для каждого просмотра был показан еще до того, как пользователь выбрал конкретный вид.Есть несколько пользователей, которые просматривают / добавляют / обновляют / удаляют записи. Каждый раз запуск запроса MySQL для отображения счетчика для каждого представления может быть очень интенсивным и занимать много времени, поскольку могут быть миллионы строк. Я думал об использовании memcached илиredis для хранения начального количества записей представления и последующего обновления их при возникновении изменений. Проблема здесь заключается в том, как динамически выяснить, какие запросы для какого представления выполняются во время выполнения.

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

Любые предложения о том, как решить проблему, приветствуются.

1 Ответ

1 голос
/ 05 января 2012

Вариант 1: кеширование. Запись кэша где-то учитывается (memcached, redis) и периодически запускает задание cron, которое обновляет счетчики. Используйте этот метод, если вам все равно, если ваши счетчики немного неточны.

Вариант 2. Сохранение логики маршрутизации в вашем коде. Ваш язык может или не может сделать это легко. Вот как это может выглядеть в Ruby: 

class ViewMatcher
  def initialize
    @views = {'all' => lambda{|params| true },

              'kids' => lambda{|params| params[:age] && params[:age] < 15 },

              'foo kids' => lambda{|params| params[:age] && 
                                            params[:age] < 15 && 
                                            params[:email] && 
                                            params[:email].include?('foo')}}
  end

  def print_matching_views(params)
    puts "Matching views for query: #{params.inspect}"
    result = []
    @views.each do |k, v|
      result << k if v.call(params)
    end
    puts result
    puts ""
  end
end


vm = ViewMatcher.new

vm.print_matching_views :age => 10
vm.print_matching_views :age => 20
vm.print_matching_views :age => 10, :email => 'foo@example.com'
vm.print_matching_views :age => 10, :email => 'moo@example.com'

Выход: 

Matching views for query: {:age=>10}
all
kids

Matching views for query: {:age=>20}
all

Matching views for query: {:age=>10, :email=>"foo@example.com"}
all
kids
foo kids

Matching views for query: {:age=>10, :email=>"moo@example.com"}
all
kids
...