Software teams rarely set out to build a bad data model. The failure mode is usually incremental: a single “wide” table is created to make reporting easy, then it quietly becomes the default dependency for dashboards, ad hoc queries, and downstream data products. At that point, the table is no longer a dataset. It is the interface through which the organization interprets reality.

This article explains why that interface fails, and why a star schema (facts and dimensions) is usually a more stable foundation. I will use a few examples from finance and e-commerce because the failure modes become obvious when definitions matter and changes are constant.

Overview

The problem

A single table is treated as the canonical representation of the business. It contains a mix of facts, events, and descriptive attributes. It is wide, convenient, and fragile.

The consequences

• Reports require long, fragile filters to make the table “mean” what the report needs.
• Metrics drift because the grain of the table is unclear or changes over time.
• Costs spike when slow-moving dimensions change and the wide table must be rebuilt.
• Finance-style reconciliation gets harder because provenance is obscured by pre-joins, re-joins, and duplicated attributes.

The root cause

The table does not have a stable grain. It mixes events, state, and descriptive attributes in one place, so correctness becomes a matter of convention. Conventions do not scale.

The core problem is not width. It’s grain.

The key question is simple: what is a row?

In a wide table, the honest answer is often: “It depends.”

In finance-themed systems, that ambiguity shows up fast. Is each row:

• a payment attempt?
• a settlement transaction?
• a journal entry line (a debit or a credit)?
• a status update?
• both sides of a posting for some transactions but not others?

If the grain is unclear, every report pays a “filter tax” to coerce the table into a specific meaning:

• include only status = 'SETTLED' but exclude chargebacks and reversals
• remove duplicates with a window function that only one person understands
• use amount_gross for card payments, but amount_net for bank transfers
• exclude internal accounts, except when doing liquidity

This is why wide tables feel productive at first, then confusing later. The confusion is not a user problem. It is a modeling problem.

The cost trap: slow-moving dimensions force large rewrites

Any domain has slow-moving attributes. In e-commerce, they are usually “reference data” that looks harmless until it forces a rebuild:

• product taxonomy and category mappings
• brand and supplier attributes
• SKU-to-product rollups (and the inevitable re-parenting)
• fulfillment rules (warehouse, region, carrier service levels)
• tax nexus / VAT mappings and rate tables
• marketing attribution mappings and channel classifications

In a star schema, those attributes live in dimension tables. When a classification changes, you update the dimension (sometimes with history). Your facts stay stable.

In a “one wide table” design, those attributes are copied into every row that references the entity. When a slow-moving attribute changes, you get a choice between two bad options:

1. Leave old values in place and accept inconsistent reporting depending on date ranges and filters.
2. Backfill the wide table so historical rows contain the updated attribute.

Option 2 can be operationally expensive. A small change like “reclassify 3,000 SKUs into a new taxonomy” can translate into a rewrite of a large fraction of your most queried table, followed by re-running downstream dependencies. In cloud warehouses, this is often a real cost spike, not a theoretical concern.

The cost is not only compute. It is also time, incident risk, and the opportunity cost of tying up your pipeline in a backfill because a mapping changed.

A star schema makes the questions answerable

A star schema starts by making the grain explicit and non-negotiable.

For many transaction-oriented products, a common anchor is an event-level fact:

• fact_transactions (grain: one row per transaction event)

Then you attach dimensions that describe that event:

• dim_customer
• dim_card_details
• dim_config
• dim_billing_address
• dim_fraud_result

If you also need lifecycle analytics, you add separate facts with their own grains:

• fact_orders (one row per order)
• fact_refunds (one row per refund)

The point is that each fact table answers “What is a row?” in a way that survives growth and product changes.

What about convenience?

You can still give users a wide view. The difference is that it is a derived view, not the canonical storage of truth.

In other words:

• Star schema is the model.
• Wide tables are interfaces.

That separation is what keeps change cheap.

A practical migration path from “one table” to a star

If you already have a wide table, you do not need a big rewrite to improve things.

1. Pick one critical report and write down the grain it assumes.
2. Create one fact table at that grain (posting-level is often a good anchor for finance).
3. Move slow-moving attributes into dimensions. Keep them out of the fact except for stable keys.
4. Recreate the old wide table as a view that joins facts to dimensions.
5. Add data quality checks where it matters: balancing rules, reconciliation counts, and uniqueness at the chosen grain.

You will still have joins, but you will also have a model that can explain itself.

Closing

The “one wide table” looks like a shortcut to a single source of truth. In practice, it tends to become a single source of ambiguity and cost.

A star schema is not about aesthetic purity. It is a way to keep grain explicit, keep slowly changing attributes manageable, and keep reports consistent when the business changes.