Should monthly data be stored in new columns or new records?

Prefer new rows (one period per record), not new columns for each month. Years and months stay data—not schema.

(Diagram: avoid Jan/Feb columns; store period + metric + value as rows.)

Suggested shape

Metrics (or monthly facts) table

• Period (month start date, or year + month fields)
• Metric name (revenue, count, …) or link to a metric definition
• Value, currency if needed
• Optional: entity (customer, product) via link

To add April you insert a row. Charts and filters work on Period instead of hunting Col_Apr.

(Local demo: period and value as ordinary fields.)

How to verify

• Filter Period within one quarter—you should get three rows per metric, not three columns.
• Year-over-year = filter two years and compare values; no new worksheet.

Boundaries

• Wide Excel months-as-columns fight every new year and every new metric.
• If you truly need a crosstab for reading, build a view or export later—don’t freeze that shape into the Base fields.
• Keep “business period” separate from created-time so late entry doesn’t land in the wrong month (see also backfill-date guidance on the forum).

Rows scale; column-per-month does not.

Day-to-day

1. Decide the grain (month vs day) once and stick to it in Period.
2. Enter or import one row per period per metric.
3. Build views: “This year”, “Last 12 periods”, maybe a chart later.
4. When finance adds a new KPI, add rows (or a metric type)—not a new column named after the KPI×month.

Prompt you can give an agent

Migrate our spreadsheet that has one column per month into a Busabase table with Period, Metric, Value (and Entity if needed). Map each non-empty cell to one row. Do not create month columns.

That keeps history queryable without yearly redesigns.