# Relatório Completo de Migração: Supabase/PostgreSQL para MySQL Enterprise

## 1. Visão Geral
Este relatório detalha o processo de migração da infraestrutura baseada em Supabase/PostgreSQL para um sistema puramente baseado em MySQL, otimizado para um cenário empresarial multi-tenant. A migração foi desenhada para não quebrar funcionalidades existentes, garantindo que todo o histórico e lógica de negócio permaneça intacto.

## 2. Problemas Encontrados na Estrutura Anterior
Durante a análise dos schemas originais, foram identificados os seguintes problemas que impossibilitavam uma escala empresarial segura:
1. **Acoplamento Extremo ao Supabase Auth**: As tabelas dependiam do schema `auth.users` e das funções `auth.uid()`, tornando impossível exportar a lógica de autenticação.
2. **Lógica RLS (Row Level Security) Insegura em Carts**: Acesso ao carrinho de compras dependia de um `session_id` frágil, permitindo visualizações não autorizadas em cenários sem sessão correta.
3. **Escalabilidade Multi-Tenant Mista**: O campo `tenant_id` foi adicionado numa migração tardia (`20260427123100_add_tenant_id_columns.sql`) mas faltava em tabelas críticas como `categories` e `carts`.
4. **Acoplamento de Lógica Transacional**: Utilização de triggers do Postgres para lógica de negócio (ex: atribuir admin se o email fosse amadoraimprime@gmail.com) que não escala bem quando o código não é versionado junto com a aplicação.
5. **Falta de Idempotência nos Webhooks**: A tabela `payments` não possuía uma tabela de buffer para gerir a concorrência e eventuais falhas nos callbacks das gateways.

## 3. Correções Aplicadas na Nova Estrutura MySQL
1. **Desacoplamento de Autenticação**: Criada uma tabela nativa `users` que substitui por completo o Supabase Auth. Introdução dos campos `password_hash` para utilização de bcrypt/argon2 no backend, e `tenant_id` para isolamento de clientes.
2. **Isolamento Multi-Tenant Total**: Adicionado o `tenant_id` em todas as tabelas transacionais (Categories, Products, Carts, Orders, Payments, Invoices) com Foreign Keys e Cascades devidamente configurados para garantir que não existem leaks de dados.
3. **Conversão de Tipos e Funções**: 
   - `gen_random_uuid()` alterado para UUIDs em MySQL (`VARCHAR(36)` gerados via Triggers).
   - `JSONB` convertido para o tipo nativo `JSON` do MySQL 8+.
   - Substituição do `timestamp with time zone` por `TIMESTAMP DEFAULT CURRENT_TIMESTAMP`.
4. **Idempotência nos Pagamentos**: Criada a tabela `webhook_logs` e constraints `uk_provider_event` para prevenir Replay Attacks.
5. **Stored Procedures Seguras**: Lógica de pagamento movida para a stored procedure `sp_process_order_payment`, garantindo ACID Compliance total e protegendo o Stock de *race conditions*.

## 4. Queries Convertidas (Exemplos Práticos)

**PostgreSQL (Antigo - com RLS dependente de auth.uid):**
```sql
SELECT * FROM orders WHERE user_id = auth.uid();
```
**MySQL (Novo - via Backend Node/PHP/Go):**
```sql
-- O Backend injeta os IDs de forma segura, usando Prepared Statements
SELECT * FROM orders WHERE tenant_id = ? AND user_id = ?;
```

**PostgreSQL (Inserção com gen_random_uuid):**
```sql
INSERT INTO categories (name) VALUES ('T-Shirts');
```
**MySQL (Novo):**
```sql
-- O Trigger MySQL preenche automaticamente o UUID se omitido
INSERT INTO categories (id, tenant_id, name) VALUES (UUID(), ?, 'T-Shirts');
```

## 5. Segurança Implementada
- **Prepared Statements Obrigatórios**: Toda a interação da camada aplicacional deve agora utilizar Prepared Statements (proteção total contra SQL Injection).
- **Proteção de Escalada de Privilégios**: Um trigger em `users` previne que contas atualizem a sua coluna `role` sem contexto administrativo.
- **Isolamento de Tenants (Data Segregation)**: As chaves compostas e Foreign Keys impedem acidentalmente carregar produtos de outros lojistas na mesma Query sem fornecer o `tenant_id`.
- **Validação de Webhooks**: Implementação descrita no documento anexo `payment_webhook_architecture.md`.

## 6. Próximos Passos
1. Substituir referências Supabase (`@supabase/supabase-js`) na aplicação cliente por chamadas API diretas ao novo Backend.
2. Configurar Prisma/Drizzle ORM conforme descrito no guia de adaptação.
3. Iniciar plano de Data Migration usando um script ETL para migrar os dados do Postgres atual para o novo MySQL.