# Schema alvo (proposta) — CMS + Builder

Esta proposta assume:

- conteúdo normalizado (imagens em tabela própria)
- homepage/builder configurável por edition
- compatível com 2 estratégias de multi-edition:
  - **DB por edition** (cada site/edition tem a sua BD)
  - **DB única** com partilha entre editions

## 1) CMS (conteúdo)

### `articles`

- `id` (PK)
- `title`
- `slug` (único “global” OU por política editorial; ver abaixo)
- `body` (longtext)
- `status` (`draft|pending|live|archived`)
- `published_at`, `expires_at`, `created_at`, `updated_at`
- `author_id` (opcional)
- `legacy_article_id` (opcional, para migração)

#### Artigos comuns a todas as editions (dados globais)

Confirmado: `town_id`, `regions`, `categories`, `subjects`, `threads` são consistentes/partilhados entre todas as editions.
Mas a edition **não** precisa estar ligada a `town_id`/`region_id`: a homepage é curada manualmente.

Logo:

- existe **uma só** coleção de conteúdo (tabelas globais)
- a “edition” é uma **vista** (filtro) do conteúdo com base em regras (ex: towns/regions)

Ainda assim, para backoffice e controlo editorial, é útil manter uma relação materializada:

- `article_editions` (N:N) para permitir overrides manuais e estado/publish por edition (opcional)
  - não é obrigatório para a homepage (que é manual)

### Taxonomias

Taxonomias globais (partilhadas):

- `categories` (migrar de `articles_categories`)
- `subjects` (migrar de `subjects`, com associação a `articles_categories` via `subjects.article_category_id`)
- `threads` (migrar de `threads`)

Relações recomendadas (para permitir 1..N no futuro sem “coluna única”):

- `article_categories` (article_id, category_id)
- `article_subjects` (article_id, subject_id)
- `article_threads` (article_id, thread_id)

Se quiseres manter “1 artigo pertence a 1 thread/subject/category”:

- pode ficar como FK direta em `articles`, mas o N:N dá mais flexibilidade e simplifica o builder.

### `images`

Tabela única para imagens do sistema:

- `id`
- `path`/`url` + metadados (`width`, `height`, `alt`)
- `created_at`

Associação:

- `article_images` (article_id, image_id, role, sort_order)
  - `role` ex: `featured|inline|gallery|slider`

## 2) Builder (drag & drop)

### `editions`

Se for DB por edition, esta tabela pode viver numa BD “central” do admin:

- `id`
- `key` (murciatoday, alicantetoday, ...)
- `name`
- `hosts` (json)
- `db_group` (nome do group/ligação)
- branding (json)

### `homepage_layouts`

- `id`
- `edition_id`
- `layout_json` (json)
- `updated_at`

`layout_json` (exemplo conceptual):

- hero: 6 slots
- sections: lista ordenada
- cada bloco referencia `sourceType` + `sourceId` + `limit`
  - o “universo” é sempre a edition atual, mas as taxonomias são globais: a edition só filtra artigos (por town/region, etc.)

## 3) Migração (o que falta do dump)

Para fechar o modelo final faltam do teu lado:

- tabela de **categorias** (a que corresponde a `article_category_id`/`category_id`)
- confirmar se `articles` tem 1 ou múltiplas categorias/subjects/threads na prática