Home/ Questions/Q 390827
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T16:00:09+00:00

As my Rails app matures, it’s becoming increasingly apparent that it has a strong

  • 0

As my Rails app matures, it’s becoming increasingly apparent that it has a strong data warehouse flavour, lacking only a facts table to make everything explicit.

On top of that, I just read Chapters 2 (Designing Beautiful APIs) and 3 (Mastering the Dynamic Toolkit) of Ruby Best Practices.

Now I’m trying to figure out how best to design the fact-retrieving part…

Say I have the following dimensions (existing Models in the app):

  • Product (contains funds)
  • Fund
  • Measure (e.g. total holding, average holding, average exposure)

… and a good old general-purpose Fact:

  • Fact (date, value, plus a foreign-key NULLable column for each of my dimensions)

Some aspects on which I’d be grateful to get some advice:

  • What might constitute a flexible retrieval interface?
  • What happens if I have Facts with both NULL (i.e. all, or don’t care) and NOT NULL (specific) values for a dimension? A pseudo-value like :all? Or should some convention apply?
  • How to select only a subset of dimension values? Or exclude a subset? :only and :exclude?
  • Has anyone had experience with creating named_scopes to deal with this? There’s the obvious attraction of being able to chain one for each dimension of interest, but does it get too clunky if we get to 7 or 8 dimensions?

(I’m aware that an acts_as_fact plugin is reputed to exist in some form (at least, there was some small buzz at RailsConf 2006) but I couldn’t find any code or description of how it might have worked.)

Versions: Rails, ActiveRecord 2.1.2, Oracle Enhanced Adapter 1.2.0

EDIT: I looked at ActiveWarehouse and have some reservations:
– the main branch hasn’t had a commit since Nov-08 and no there’s activity at all since Jan-09;
– the tutorial dates to 2006, is admitted to be out of date, and 404s on me;
– it seems to be wanting to get away from ActiveRecord – much of my app will stay in AR and I think at present that I want an AR solution.

So I’ll steer clear of that one, thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    So we have a number of gems or plugins of varying degrees of complexity, none of which seem to be very actively under development (or there’s something going on but it’s under the radar).

    In any case, I’m not looking to build a data warehouse, just to implement a fact table or two in star schema style. What I was asking for was ideas on how to access such a table.

    I’m leaning towards dropping the idea of multiple-levels, where an aggregate across a dimension would have a NULL in the foreign key for that dimension. While it would reduce the number of rows involved in a query the benefit would be small and not free: I’d have a larger fact table and more complex code.

    Retrieval looks like it might then be handled with a set of named_scopes, one for each dimension, for filtering. Or a custom finder, fed with a suitably-constructed Hash, might be better.

    When I’ve built it, I’ll come back with some better information…

    • 0