0
假设我创建了一个游戏，用户可以通过在线市场提交购买和出售商品的请求。每个销售请求可以包含多种商品类型的“子请求”。每个购买请求只能满足其中一个子请求，并且父级销售请求不再有效/可用。 （如果您愿意，请将市场动态搞砸，但请耐心等待......）嵌套/小数对象的维度模型聚合
我想汇总此数据以开始了解和分析趋势。为了论证的缘故，让我们假设在市场中有足够的行为，我无法有效地存储和/或查询原始事务级别的数据，因此我必须使用聚合。
每卖出请求生成一个日志条目大约是这样的：
{
sellRequestID: 123,
userID: 456,
timestamp: 1449043403,
country: "United States",
goods: [ "eggs", "beef", "chicken" ]
}
一个买入请求可能大约生成日志条目是这样的：
{
buyRequestID: 987,
sellRequestID: 123,
userID: 789,
timestamp: 1449043408,
good: "eggs"
}
我希望能够回答的问题如：
- 按日期和国家提交的销售请求总数是多少？
- 按天和国家提交的个别商品销售请求（子请求）的总数是多少？ （在某种程度上，这揭示了“要求通胀因素”，或每个出售请求的平均商品数量）。
- 按日，国家和类型提交的子请求总数是多少（即卖方市场中每件商品的“可用性”是多少）？
假设我有比较标准的维度表：
Date CountryID Total Requests
2015-12-01 1 1,000,000
2015-12-01 2 200,000
...
一个表，可以回答我的第二个问题和第三个：
users countries goods
----- --------- -----
456 John Smith 1 United States 1 eggs
789 Jane Doe 2 Canada 2 beef
... ... . ... 3 chicken
，可以回答我的第一个问题可能是这样的表问题可能如下所示：
Date CountryID GoodID Total Requests
2015-12-01 1 1 600,000
2015-12-01 1 2 300,000
2015-12-01 1 3 400,000
...
有没有可以让我在单个表格中回答所有问题的设计？我考虑过一些可能性，并且正在寻找任何实践经验或建议。
如果我使用上面的第二个模式，当试图回答问题1时，我最终会夸大父请求的数量，并且会失去“重复删除”这些父请求数的能力。
一种方法可能是使用像模式：
Date CountryID GoodID Parent Requests Child Requests
如果我这样做，以避免在现有情况下的通货膨胀，我需要“分成几部分”父请求 - 例如包含三件商品的请求仍会将三行中的子请求列添加1，但会将三分之一添加到父请求聚合中。类似地，具有两种商品的请求将在其两行中的父请求列上加1/2。所以我可能有这样的数据：
Date CountryID GoodID Parent Requests Child Requests
2015-12-01 1 1 1/3 1
2015-12-01 1 2 5/6 2
2015-12-01 1 3 5/6 2
现在我聚集父请求（忽略goodID）列将总结到预期的2个请求，但我仍然保留了解到，在2所父请求的能力，我有机会买一次鸡蛋，牛肉两次，鸡肉两次。
这种分数方法有什么缺点吗？我是否试图让一些不应该成为鞋子的东西刺激？提前致谢。