5

随着我的 Rails 应用程序的成熟，越来越明显的是它具有强大的数据仓库风格，只缺少一个事实表来使所有内容都变得清晰。

最重要的是，我刚刚阅读了Ruby 最佳实践的第 2 章（设计漂亮的 API）和第 3 章（掌握动态工具包）。

现在我想弄清楚如何最好地设计事实检索部分......

假设我有以下维度（应用程序中的现有模型）：

  • 产品（包含资金）
  • 基金
  • 衡量（例如总持股、平均持股、平均曝光）

...还有一个很好的通用事实：

  • 事实（日期、值以及我的每个维度的外键 NULLable 列）

在某些方面，我将不胜感激获得一些建议：

  • 什么可以构成一个灵活的检索界面？
  • 如果我的 Facts 具有一个维度的 NULL（即全部或不关心）和 NOT NULL（特定）值，会发生什么？像:all? 还是应该适用一些约定？
  • 如何仅选择维度值的子集？还是排除一个子集？:only 和 :exclude?
  • 有没有人有创建named_scopes 来处理这个问题的经验？能够为每个感兴趣的维度链接一个明显的吸引力，但是如果我们得到 7 或 8 个维度，它会变得太笨重吗？

（我知道一个acts_as_fact插件被认为以某种形式存在（至少，在 RailsConf 2006 上有一些小嗡嗡声），但我找不到任何代码或关于它如何工作的描述。）

版本：Rails、ActiveRecord 2.1.2、Oracle 增强适配器 1.2.0

编辑：我查看了 ActiveWarehouse 并有一些保留意见： - 主分支自 2008 年 11 月以来没有提交，自 09 年 1 月以来根本没有任何活动；- 教程可以追溯到 2006 年，承认已经过时了，我的 404s；- 它似乎想要摆脱 ActiveRecord - 我的大部分应用程序将留在 AR 中，我认为目前我想要一个 AR 解决方案。

所以我会避开那个，谢谢！

4

4 回答 4

2

如果我的 Facts 具有一个维度的 NULL（即全部或不关心）和 NOT NULL（特定）值，会发生什么？像 :all? 这样的伪值 还是应该适用一些约定？

NULL 会误导投标，因为它代表没有关联。我会使用类似的值-1（如果它是一个只有值 > 0 的整数外键）。

如何仅选择维度值的子集？还是排除一个子集？

with_scope()

您还可以覆盖查找功能

   def self.find(*args)
    if  anything
      with_scope(a_scope) do
         result = super *args
      end
    else
      result = super *args
    end
   end

   def self.a_scope
    {:find => { :conditions => ["person_id  = ?", me] , :readonly => true}}
   end

有没有人有创建 named_scopes 来处理这个问题的经验？能够为每个感兴趣的维度链接一个明显的吸引力，但是如果我们得到 7 或 8 个维度，它会变得太笨重吗？

我们有一个 4 维的 olap 数据库，它工作得很好。我认为，如果您为 active_record 实现一些自定义方法，您将在您的应用程序中获得乐趣。

我还发现了这个：http: //github.com/aeden/activewarehouse/tree/master

于 2009-08-03T15:56:51.853 回答
1

还有一个我没用过，但看起来不错：

http://github.com/wvanbergen/active_olap/tree/master

http://techblog.floorplanner.com/2008/07/29/active-olap-released/

这是我在谷歌找到的SOLR

http://code.google.com/p/kettle-solr-plugin/

于 2009-08-04T00:50:13.527 回答
1

不久前我正在研究使用ActiveWarehouse，然后才开始使用其他东西，所以我不能告诉你它的效果如何，但它可以添加到你的列表中以进行检查。它具有事实、维度和多维数据集的生成器以及 ETL 工具包。

于 2009-08-04T08:16:22.283 回答
0

因此，我们有许多复杂程度不同的 gem 或插件，但似乎都没有非常积极地在开发中（或者正在发生一些事情，但它在雷达之下）。

无论如何，我不打算建立一个数据仓库，只是为了实现一个或两个星型模式风格的事实表。我要的是关于如何访问这样一个表的想法。

我倾向于放弃多层次的想法，其中跨维度的聚合将在该维度的外键中具有 NULL。虽然它会减少查询中涉及的行数，但好处会很小而且不是免费的：我会有一个更大的事实表和更复杂的代码。

检索看起来可能会使用一组 处理named_scopes，每个维度一个，用于过滤。或者，使用适当构造的 Hash 提供的自定义查找器可能会更好。

当我建立它时，我会回来提供一些更好的信息......

于 2009-09-29T21:27:11.623 回答