Investigate more flexible table models #19
Description
A user questioned why we need the restriction of defining tables as either metric/fact tables or dimension tables. This organization is currently important to zillion's understanding of how to appropriately form queries and to somewhat following the data warehousing ideas outlined by Kimball. I think it's worth investigating a more flexible model, perhaps controlled/allowed by a mode flag in the zillion config, that doesn't require you label your tables as metric or dimension tables in your config and instead determines how the tables must act dynamically to satisfy a report request. In other words, when a metric is requested from a table treat it like a metric table for the scope of that report request, etc.
Disclaimer: this may be a bad idea. It's possible this could make it too easy for users to have zillion put together bad queries/reports based on a poorly defined warehouse structure. But if there are cases where this would be valuable then I would lean towards letting users utilize this at their own risk, assuming I can manage to fully understand and explain the caveats and gotchas.