# ANALISE_DE_COMPATIBILIDADE_MARIADB_FINAL

## Status

Na V2 FINAL, **MariaDB 10.6+ é a escolha oficial** do banco central.

Este arquivo permanece no pacote final como registro técnico das decisões de compatibilidade e das diferenças em relação à modelagem anterior em PostgreSQL.

---

## 1. O que continuou igual em nível conceitual

Independentemente do SGBD, o desenho continua:

- banco central separado dos bancos operacionais;
- ERP fora do caminho crítico;
- identidade do portal separada da identidade interna do ERP;
- catálogo, assinatura, billing e entitlement centralizados;
- integração futura por adaptadores, jobs e outbox.

---

## 2. O que a V2 FINAL resolveu em MariaDB

### 2.1 Unicidade condicional
Onde PostgreSQL usaria `partial unique index`, a V2 FINAL usa:

- colunas geradas;
- `NULL` fora da regra;
- `UNIQUE` sobre a coluna gerada.

Casos principais:

- único principal por cliente;
- um trial ativo por cliente/produto;
- limites de multiplicidade de assinatura/instância;
- um token ativo por usuário em fluxos de identidade.

### 2.2 Sobreposição de preços
Onde PostgreSQL usaria `exclusion constraint` com range, a V2 FINAL usa:

- procedure;
- trigger em insert/update;
- `GET_LOCK()` por chave lógica.

Resultado: não há duas janelas ativas sobrepostas para o mesmo `plano_produto + ciclo + moeda`.

### 2.3 Regras de cupom
Em PostgreSQL seria possível fechar parte da lógica com mais apoio em constraints e índices especializados.  
Em MariaDB, a V2 FINAL fecha a regra com:

- procedure de validação;
- triggers em `cupom_usos`;
- locks lógicos por alvo e cupom;
- índice de apoio por cupom/status e por alvo/status.

### 2.4 Escopos polimórficos
PostgreSQL e MariaDB têm a mesma limitação estrutural aqui: escopo polimórfico não vira FK simples.

Na V2 FINAL em MariaDB, isso foi resolvido com:

- `CHECK` para `global` vs `não global`;
- trigger de validação do destino real;
- trigger anti-órfão em exclusão das entidades alvo.

### 2.5 MFA derivado
Em vez de confiar só na aplicação para sincronizar `mfa_habilitado`, a V2 FINAL usa triggers em MariaDB para manter coerência entre:

- `usuarios_plataforma`
- `mfa_fatores`

---

## 3. O que continuaria mais elegante no PostgreSQL

Se no futuro houver motivo forte para mover o banco central para PostgreSQL, os principais ganhos continuam sendo:

- exclusion constraint nativa para intervalo de preço;
- partial indexes nativos;
- JSONB mais rico;
- mais opções nativas para consultas estruturadas complexas.

---

## 4. O que pesa a favor de MariaDB neste cenário

Para o cenário atual da plataforma, MariaDB continua mais vantajoso por:

- aderência ao stack já existente;
- menor custo de operação;
- mesma família de driver/conector PHP;
- menor complexidade de backup e administração;
- menor atrito para o time técnico no congelamento desta versão.

---

## 5. Conclusão

A V2 FINAL fecha em MariaDB sem perda conceitual da arquitetura.

As diferenças para PostgreSQL estão concentradas em **como** a integridade é implementada, não em **o que** o modelo representa.

Ou seja:

- a arquitetura permanece correta;
- o ERP segue protegido;
- as regras críticas continuam no banco;
- MariaDB reduz fricção operacional para colocar esse núcleo central em produção.