RavenDB — сложное агрегирование MapReduce

Предполагая, что ваши классы выглядят так:

public class Order
{
  public string Id  { get; set; }
  public List<Event> Events { get; set; }
}

public class Event
{
  public DateTime Timestamp { get; set; }
  public string EmployeeName { get; set; }
}

Тогда индекс, который вы запрашиваете, будет выглядеть так:

public class Orders_EventCountsByDate : 
    AbstractIndexCreationTask<Order, Orders_EventCountsByDate.Result>
{
  public class Result
  {
    public DateTime Date { get; set; }
    public double Count { get; set; }
  }

  public Orders_EventCountsByDate()
  {
    Map = orders => from order in orders
                    from evt in order.Events
                    let subtotal = order.Events.Count(x => x.EmployeeName == evt.EmployeeName && x.Timestamp == evt.Timestamp)
                    select new
                    {
                      evt.Timestamp.Date,
                      Count = subtotal > 1 ? (1.0 / subtotal) : 0
                    };

    Reduce = results => from result in results
                        group result by result.Date
                        into g
                        select new
                        {
                          Date = g.Key,
                          Count = g.Sum(x => x.Count)
                        };
  }
}

И вы бы использовали его так:

var counts = session.Query<Orders_EventCountsByDate.Result,
                           Orders_EventCountsByDate>();

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

Это также предполагает, что все события происходят в одном и том же часовом поясе, и вас не волнуют изменения летнего времени или время указано в формате UTC. Если ни то, ни другое, то вам следует использовать DateTimeOffset, и вам нужно больше учитывать при принятии решения о том, что представляет собой концепция дня каждого сотрудника.