You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: