# Estrutura atual (dump stagingm_murcia.sql) — notas

Ficheiro analisado: `stagingm_murcia.sql`

## Tabelas encontradas (relevantes para o refactor)

- `articles`
- `articles_hp` (subset/cache para homepage)
- `articles_categories` (dump separado: `articles_categories.sql`)
- `subjects`
- `threads`
- (também existem `regions`, `towns`, etc.)

## O que NÃO aparece neste dump (provavelmente noutro dump/schema/db)

- Tabelas de relação N:N (se existirem) entre artigos e taxonomias.

## Colunas importantes em `articles` (resumo)

- Identificador: `article_id`
- Taxonomias (tudo como *id* varchar):
  - `thread_id`, `subject_id`, `category_id`, `article_category_id`
  - ainda: `region_id`, `town_id`
- Conteúdo:
  - `heading` (título), `content` (corpo)
- Estado:
  - `status` (`Pending|Live|Archive`)
- Datas (parecem timestamps/ints “legacy”):
  - `create_date`, `publish_date`, `expiry_date`
- Imagens (a normalizar):
  - `image1..image12` (+ `img_size*` + alinhamentos/crops)
  - `gallery_image1..gallery_image24`
- Slider (a normalizar):
  - `slideimage1..8`, `slidetext1..8`, `slidelink1..8`

## `articles_hp`

Tabela muito parecida com `articles`, mas com menos colunas (usada para performance na homepage).
No refactor podemos:

- manter como **materialized/cache** (gerada por cron/trigger)
- ou substituir por cache/app-level, dependendo do volume e do MySQL