Pular para o conteúdo principal

Bancos Suportados (Postgres / SQL Server)

O backend (HSBR-Gestao-Ativos-Back) roda em PostgreSQL ou SQL Server 2019+, escolhido pela variável DB_ENGINE (postgres — padrão — ou sqlserver). O acesso a dados é híbrido: Prisma para os modelos fixos e SQL cru engine-aware (via dbStrategy/) para as tabelas dinâmicas de EPC.

Como a seleção funciona​

DB_ENGINE é lido em três lugares que precisam concordar:

  • Runtime — src/config/database.ts + src/lib/prisma.ts escolhem o adapter (pg ou mssql).
  • Prisma CLI — prisma.config.ts escolhe o schema, a pasta de migrations e monta a connection URL a partir das DB_*.
  • Build — scripts/prisma-generate.mjs (chamado pelo npm run build).
O client Prisma é "assado" por engine no BUILD

O Prisma fixa o provider e os tipos de coluna na hora de gerar o client, e o npm run build compila esse client na imagem. Por isso um deploy SQL Server precisa de uma imagem buildada com DB_ENGINE=sqlserver — a imagem GHCR padrão (:develop, :main) é Postgres e não roda contra SQL Server.

Duas histórias de migration​

Como o SQL diverge entre os bancos, as migrations não são compartilhadas:

EngineSchemaMigrations
Postgresprisma/schema.prisma (canônico — edite este)prisma/migrations/
SQL Serverprisma/schema.sqlserver.prisma (derivado, gitignored)prisma/migrations-sqlserver/

O schema do SQL Server é derivado do canônico por scripts/build-sqlserver-schema.mjs (remapeia Timestamptz→DateTimeOffset, VarChar→NVarChar, e Json/arrays → NVarChar(Max) — SQL Server não tem JSON/array nativo; os repositórios serializam/desserializam na borda via src/lib/jsonColumn.ts). As tabelas dinâmicas de EPC usam SQL cru engine-aware, não Prisma.

O entrypoint do container roda um npx prisma migrate deploy simples, que já é engine-aware via prisma.config.ts — então não há verbo de migrate separado por engine em produção.

Rodar localmente​

Postgres​

cd HSBR-Gestao-Ativos-Back
docker compose -f docker-compose.postgres.yml up -d     # Postgres descartável (porta 15432)
# .env: DB_ENGINE=postgres DB_PORT=15432 DB_USER=postgres DB_PASSWORD=postgres DB_NAME=hsbr
npm run prisma:generate
npx prisma migrate deploy
npm run db:seed
npm run dev

SQL Server 2019​

O detalhe importante: regenerar o client para sqlserver antes de seed/run.

cd HSBR-Gestao-Ativos-Back
docker compose -f docker-compose.sqlserver.yml up -d     # mssql + cria o DB
# .env: DB_ENGINE=sqlserver DB_PORT=1433 DB_USER=sa DB_PASSWORD='Your_strong_Pass123'
#       DB_MSSQL_ENCRYPT=true DB_MSSQL_TRUST_CERT=true
DB_ENGINE=sqlserver npm run prisma:generate
DB_ENGINE=sqlserver npm run db:push:sqlserver     # ou db:migrate:deploy:sqlserver
DB_ENGINE=sqlserver npm run db:seed
DB_ENGINE=sqlserver npm run dev

Imagens por engine (CI)​

O workflow publish-ghcr.yml publica uma imagem por engine (build matrix):

  • postgres → mesmos nomes/tags de sempre (:develop, :main, :sha-…).
  • sqlserver → mesmo repositório, com sufixo -sqlserver na tag (ex.: :develop-sqlserver), buildada com --build-arg DB_ENGINE=sqlserver.

Qual usar?​

  • Postgres é o padrão (dev, CI, maioria dos deploys).
  • SQL Server é para clientes on-premise que exigem SQL Server. Pontos de atenção:
    • SQL Server 2019 pede ~2GB+ de RAM (pesado num VPS compartilhado).
    • As imagens de dev/e2e usam MSSQL_PID=Developer (não licenciado para produção) — produção precisa de edição/licença adequada do SQL Server.
    • Licença HSBR offline (.lic) costuma ser o encaixe (veja Licenciamento); o Integration Hub fica desabilitado.

Deploy em SQL Server (DevOps)​

O DevOps/docker agora suporta SQL Server. O engine é só uma variável no .env do ambiente (DB_ENGINE=sqlserver); o deploy.sh/deploy-stack.sh layeram o override docker-compose.sqlserver.yml automaticamente (imagem …-sqlserver + conexão DB_MSSQL_* + hub desligado). A licença é sempre Postgres; só o hsbr-back muda de engine.

Para o passo a passo do banco em si (container via script, banco externo/gerenciado, ou tudo de uma vez — Postgres ou SQL Server), veja Banco de dados do deploy.

Runbook (um grupo HSBR em SQL Server, modelo B):

cd DevOps/docker
cp .env.example .env.cliente-acme    # edite:
#   COMPOSE_PROFILES=hsbr
#   DB_ENGINE=sqlserver
#   DB_MSSQL_SA_PASSWORD=...          # senha do SQL Server
#   DB_MSSQL_PORT=1433  HSBR_DB_NAME=ga6
#   HSBR_BACK_IMAGE_TAG=develop       # vira develop-sqlserver no deploy
#   HSBR_BACK_JWT_SECRET=...  HSBR_LICENSE_KEY=<uuid>  NEXT_PUBLIC_URL_BASE_APP=https://...
#   LICENSE_SERVER_URL=https://license...   (profile hsbr)

# 1. Banco SQL Server (pule se usar um instance gerenciado/existente):
./scripts/db-sqlserver.sh --env cliente-acme        # sobe o container + cria o DB

# 2. Stack (front+back) — engine lido do .env:
./scripts/deploy-stack.sh cliente-acme              # == deploy.sh --env cliente-acme

# 3. Nginx + TLS:
sudo ./scripts/setup-nginx.sh --env cliente-acme --certbot

Pré-requisito: a imagem …-sqlserver precisa existir no GHCR (CI publica) — ou use ./scripts/deploy-stack.sh cliente-acme --build para buildar do fonte. A licença: gere uma nova para o tenant (online via LICENSE_KEY, ou .lic offline) — veja Licenciamento.

Backups: o backup-db.sh atual é pg_dump (não cobre SQL Server). Para o banco SQL Server use BACKUP DATABASE/sqlcmd ou o backup do instance.

Para testar full-stack em SQL Server sem deployar, use a suíte E2E (npm run test:e2e:docker:sqlserver) — veja Testes E2E.