Migrar Paradox e BDE de forma controlada para MariaDB

Muitas aplicações setoriais Delphi nasceram com tabelas Paradox e a Borland Database Engine (BDE), porque isso era na época um padrão pragmático: local, rápido para iniciar, pouca infraestrutura. Na prática, esses sistemas frequentemente ainda rodam em produção – incluindo reporting, impressão de etiquetas, import/export, jobs em lote, tabelas de histórico e lógica especial que se „inseriu“ no acesso a dados ao longo dos anos. Exatamente por isso uma migração não é apenas exportar os dados, mas uma reconstrução controlada: modelo de dados, comportamento SQL, efeitos colaterais no código e processos operacionais precisam ser considerados em conjunto.

MariaDB é frequentemente uma ótima escolha como plataforma alvo quando se busca operação multiusuário robusta, transações consistentes, backups centrais, replicação, uma gestão clara de privilégios e a capacidade de integração com portais web, serviços ou APIs REST. O desafio raramente é a instalação da base de dados – o esforço real está no caminho de migração seguro: como migrar corretamente tabelas, índices, chaves primárias, conjuntos de caracteres, campos de data, valores „vazios“ e relacionamentos referenciais sem quebrar a lógica de negócio em operação?

Este artigo descreve uma abordagem comprovada para migrar Paradox e BDE de forma controlada para MariaDB: tecnicamente fundamentada, por etapas e com foco em estabilidade. O objetivo é criar uma base sustentável para passos de modernização posteriores – por exemplo a substituição da BDE, migração para uma integração nativa sem BDE, arquitetura Layer-3 clara, servidores REST e clientes multiplataforma.

Por que a migração Paradox/BDE é mais do que trocar de banco de dados

Paradox como formato de ficheiro e a BDE como camada de acesso formam um sistema integrado com particularidades que não devem ser reproduzidas 1:1 em MariaDB. Sintomas típicos no dia a dia incluem:

• Dependências pouco transparentes: instruções SQL estão espalhadas (Forms, DataModules, Reports, SQL dinâmico em strings), frequentemente sem governança central.
• Comportamento „por sensação“: certos filtros, ordenações ou joins funcionam por acaso porque Paradox/BDE é tolerante ou converte tipos implicitamente.
• Limites multiusuário: locks baseados em ficheiro, quedas de desempenho na rede, problemas de locking com aumento do volume de dados.
• Riscos de manutenção: dependências da BDE, drivers antigos, deployment difícil em versões modernas de Windows, questões 64‑Bit/ARM64.

Uma migração controlada não trata esses pontos como efeitos colaterais, mas como critérios de objetivo. MariaDB deixa de ser apenas a „nova base de dados“ e passa a ser a oportunidade de desacoplar a camada de acesso a dados, aumentar a integridade de negócio e permitir interfaces padronizadas.

Visão alvo: MariaDB como base de dados estável para desktop, serviços e portais

Uma visão alvo sensata para aplicações B2B costuma ter três camadas:

• Base de dados (MariaDB): persistência consistente, índices, constraints, transações, usuários/papéis, backups.
• Lógica de negócio (Server/Services): validações, workflows, importadores, agendadores, interfaces. Opcionalmente como servidor REST, serviços Windows ou Linux.
• Clients (VCL/FMX/Web): interfaces de operação, reports, partes offline, integrações. Idealmente com contratos claros para a lógica de negócio.

Dependendo do ponto de partida, não é necessário implementar tudo de uma vez. Mas a migração deve ser planeada de modo a não obstruir o caminho para uma arquitetura limpa. Quem hoje apenas copia tabelas e amanhã volta a escrever „diretamente“ de cada form para a base de dados, introduziu MariaDB, mas manteve os riscos reais.

Levantamento: o que realmente precisa ser migrado

No início está um inventário que vai além de „quantas tabelas“. Em projetos Paradox/BDE é típico que a base de dados represente apenas parte da verdade. Pontos importantes:

1) Tabelas, índices, „pseudo-chaves“

Com frequência faltam chaves primárias reais. Em vez disso existem combinações de campos, números sequenciais sem constraint única ou campos „Key“ mantidos pela aplicação. Em MariaDB isso precisa tornar-se chaves únicas e robustas – caso contrário transações e integridade referencial terão eficácia limitada.

2) Queries, blocos SQL dinâmicos, reports

BDE usa, consoante o componente, dialetos SQL diferentes e tolera instruções „criativas“. Componentes de reporting (incluindo mais antigos) muitas vezes contêm definições SQL próprias. Uma migração deve localizar e categorizar essas fontes: queries centrais críticas, análises raramente usadas, imports especiais.

3) Conjunto de caracteres e caracteres especiais (Umlaute, ISO/ANSI, Unicode)

Muitas aplicações Paradox são historicamente baseadas em ANSI. Se a aplicação Delphi em algum momento foi adaptada para Unicode, surgem misturas: dados em codificação antiga, UI em Unicode, exportações esperando Windows-1252. MariaDB deve ter um conceito claro aqui (tipicamente utf8mb4), incluindo conversão limpa e testes para erros „invisíveis“ (comparações, ordenação, trim/pad, caracteres especiais).

4) Valores „vazios“, lógica NULL e campos de data

Paradox/BDE conhece diversos casos especiais: strings vazias em vez de NULL, datas 0, timestamps „vazios“, valores default gerados pela UI. MariaDB distingue estritamente entre NULL e vazio. Isso afeta cláusulas WHERE, agregações e cálculos. Essas diferenças devem ser avaliadas por tabela/campo.

5) Artefatos adjacentes: tabelas de sessão, configuração local, cache

Frequentemente existem tabelas locais na estrutura Paradox para resultados intermédios, buffers de exportação, layouts de utilizador ou parâmetros. Parte disso deve permanecer local (por ex. layouts de UI), outra parte deve ser centralizada (por ex. processos de trabalho, estados, logs). A migração é uma oportunidade para separar claramente essas categorias.

Armadilhas em Paradox/BDE: diferenças técnicas típicas

Para tornar a migração planeável, vale a pena abordar explicitamente as diferenças recorrentes.

Dialeto SQL e operadores

BDE/Paradox-SQL não é idêntico ao SQL de MySQL/MariaDB. Diferenças surgem, entre outras, em funções de data, funções de string, outer joins (históricos), lógica Like/máscaras e em conversões implícitas de tipo. Uma abordagem controlada substitui o „funciona assim“ por regras claras: quais statements serão portados, quais serão reescritos intencionalmente, quais serão encapsulados em Views/Stored Procedures (quando fizer sentido)?

Ordenação e collation

Em Paradox as ordens de ordenação e sensibilidade a maiúsculas/minúsculas costumam diferir de MariaDB, especialmente com Umlauts. Em MariaDB a collation (por ex. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) determina comparação e ordenação. Isso não é questão académica: influencia deduplicação, funções de busca e comportamento de constraints UNIQUE.

Autoincrement e sequências de números

Paradox tem campos autoincrement, mas aplicações frequentemente usam os próprios sequenciadores (números de documento, número de pedido) com lógica especial. Em MariaDB deve-se separar claramente:

• Chave primária técnica: AUTO_INCREMENT (ou UUID, dependendo da arquitetura) para relações.
• Número de negócio: sequência própria com proteção transacional, possivelmente por cliente/mandante/período.

Quem tenta usar um número de negócio como chave técnica acaba por ter retrabalhos dispendiosos mais tarde.

Locking e transações

A mudança de acesso por ficheiro para um servidor real é um ganho, mas altera o comportamento. Em MariaDB as transações (InnoDB) são centrais. É preciso decidir onde ficam os limites de transação: por diálogo, por operação de gravação, por lote. Importante: transações longas e modos „Edit“ por minutos são comuns em mundos Paradox, mas são críticos no lado servidor (locks, deadlocks, lag da replicação). Muitas vezes é necessário adaptar o modo de trabalho ou a UI como parte da migração.

Modelo de procedimento: migração controlada em etapas em vez de Big Bang

Em ambientes B2B a estabilidade operacional costuma ter prioridade sobre uma mudança rápida. Um caminho de migração por etapas reduz risco porque a área de negócio e a TI podem validar iterativamente.

Etapa 1: Transferência do modelo de dados com mapeamento, sem refatoração de código

No primeiro passo constrói-se um esquema MariaDB que replica a estrutura Paradox – mas já com princípios alvo: chaves primárias, índices, tipos de dado adequados, utf8mb4, InnoDB. Em paralelo cria-se um processo de importação reproduzível (scripts/ferramentas) que possa ser repetido conforme necessário. A repetibilidade é crucial, pois a migração raramente está „pronta“ na primeira execução.

Entregáveis típicos desta etapa são:

• Definição de schema (DDL) versionada (por ex. em Git)
• Lista de mapeamento de campos (Paradox → MariaDB) incluindo regras de conversão
• Procedimento de importação com logging (contagem de registos, erros, outliers)
• Primeiros relatórios de validação (counts, somas, checksums)

Etapa 2: Substituição da BDE no acesso a dados (p.ex. com FireDAC)

O passo de modernização real é o desacoplamento da BDE. Em projetos Delphi BDE-Ablosung mit nativer Anbindung é um caminho comprovado, pois oferece drivers modernos, transações, binding de parâmetros e componentes uniformes para diferentes backends SQL. O decisivo não é „tirar BDE“, mas como o código fica depois: acesso a dados centralizado, tratamento de erro claro, parâmetros limpos em vez de concatenação de strings.

Tarefas típicas nesta etapa:

• Substituir TTable/TQuery por Queries e DataSets de FireDAC
• Introduzir uma camada de Data-Access (DAL) como base para arquitetura Layer-3
• Padronizar escopos de transação (Commit/Rollback)
• Revisão SQL: adaptação de dialeto, parâmetros, paginação, joins

Se a sua aplicação deverá ser modernizada a longo prazo, este passo costuma ser mais importante do que a migração pura dos dados. Ele cria a liberdade técnica para 64‑Bit, versões modernas de Windows e pipelines de deployment limpas.

Etapa 3: Operação paralela e aceitação funcional sem interrupção

Para sistemas críticos é sensato operar em paralelo: MariaDB é criado e alimentado ciclicamente (ou incrementalmente) enquanto o sistema legado continua em operação. Assim o negócio pode comparar relatórios, identificar casos limite e testar a nova plataforma sob carga. O modo de operação paralelo pode ser implementado de formas distintas:

• Replicação read-only para preparação de reporting/BI
• „Dual Write“ em áreas definidas (somente se bem controlado)
• Migração por data de corte com múltiplos dry-runs e checklist de cutover

É importante não complicar em excesso: Dual-Write parece atraente, mas é propenso a erros se a lógica de negócio não estiver centralizada. Frequentemente um corte por data com execuções repetíveis e boa validação é economicamente mais sensato.

Etapa 4: Otimização, integridade, performance, processos operacionais

Após o cutover começa a fase em que MariaDB deve demonstrar suas vantagens: integridade referencial, índices performantes, privilégios limpos, monitorização, testes de backup/restore. É aqui que muitas vezes as cargas „reais“ de produção se tornam visíveis: reports longos, máscaras de busca mal indexadas, atualizações em lote. Uma migração controlada planeia explicitamente esta etapa em vez de deixá-la como retrabalho não planeado.

Tipos de dado e mapeamento: de Paradox para MariaDB sem perda de informação

O mapeamento de campos é o coração da migração. Associações típicas (simplificadas) são:

• Alpha / Memo: VARCHAR/TEXT (com utf8mb4), verificação de comprimento e regras de trim
• Number: INT/BIGINT/DECIMAL dependendo do intervalo de valores; cuidado com casas decimais implícitas
• Date/Time: DATE/DATETIME/TIMESTAMP; regras claras para „data 0“ vs. NULL
• Logical: BOOLEAN ou TINYINT(1) com semântica inequívoca
• Currency: DECIMAL(…,2/4) em vez de Float para evitar erros de arredondamento

É importante não apenas traduzir tipos, mas também documentar regras de negócio: um campo pode ser NULL? Quais defaults são corretos do ponto de vista funcional? Quais combinações devem ser únicas? Dessas regras derivam constraints e índices. Muitas vezes essas regras estavam implícitas no sistema Paradox/BDE (UI ou código) – em MariaDB elas devem, quando fizer sentido, tornar-se explícitas.

Integridade: chaves primárias, estrangeiras e índices únicos

Muitas bases legadas funcionam anos sem integridade referencial – até que integrações, portais ou processos paralelos aparecem. Aí a qualidade dos dados torna-se fator limitante. Em MariaDB é possível usar Foreign Keys, Unique Constraints e Checks (consoante versão/engine) para prevenir erros de dados cedo.

Um caminho prático é introduzir integridade de forma gradual:

• Primeiro chaves primárias e índices únicos nos objetos centrais (clientes, artigos, documentos)
• Depois chaves estrangeiras nas áreas estáveis
• Para tabelas „históricas“ com dados sujos: primeiro limpeza, depois constraints

Isso reduz o risco de o cutover fracassar por causa de passivos antigos e melhora significativamente a situação geral.

Performance na prática: o que muda com MariaDB

Sistemas Paradox/BDE costumam estar otimizados para „velocidade de ficheiro“: índices locais, acessos tabelares rápidos, muita filtragem no cliente. Em MariaDB o trabalho desloca-se para o servidor. Isso é positivo, mas exige estratégias claras de SQL e indexação.

Armadiilhas típicas de performance

• SELECT * em tabelas grandes, porque antes „local“ era suficientemente rápido
• Filtragem no cliente em vez de WHERE no servidor
• Falta de índices compostos para campos de pesquisa (ex.: Mandante + Status + Data)
• LIKE ‚%texto%‘ sem estratégia adequada de fulltext

Melhorar de forma mensurável em vez de „por sensação“

Uma migração controlada estabelece cedo pontos de medição: Slow Query Log, análises Explain, testes de carga reproduzíveis. Isso é especialmente importante se, após a migração, estiverem previstas componentes adicionais, como um servidor REST ou um portal de clientes que gerará padrões de acesso diferentes (muitos pedidos pequenos, paginação, endpoints de busca).

Específico para Delphi: substituição da BDE, FireDAC e camadas de acesso limpas

Em projetos Delphi a modernização técnica está intimamente ligada ao acesso a dados. A BDE não é apenas „um driver“, mas um estilo de acesso completo (TTable, baseado em registros, navegação, filtros locais). Migrar para MariaDB é o momento certo para consolidar o acesso.

De „DataSets por toda parte“ para acesso controlado a dados

Muitas aplicações têm queries próprias em cada form. Isso não escala em termos funcionais e de segurança. Uma abordagem comprovada tende para:

• Classes centralizadas de repository/service para objetos centrais
• Tratamento uniforme de erro e transações
• Queries parametrizadas (evitar SQL injection, aproveitar cache de planos)
• Pools de conexões configuráveis ou gestão de conexões para serviços

Isso cria a base para uma arquitetura Layer-3 em que UI, lógica de negócio e persistência estão claramente separadas. Essa separação ajuda não só na troca de base de dados, mas também no posterior desenvolvimento de REST-Servers ou de serviços background.

Conexão MariaDB com FireDAC: pontos que costumam surgir

Em projetos surgem sempre as mesmas questões: qual variante do driver (MySQL/MariaDB), quais opções SSL, quais opções de timezone e data, quais configurações Unicode? Não são detalhes irrelevantes, pois impactam diretamente a consistência de dados (data/hora), ordenação e segurança operacional (TLS). Uma migração controlada define esses parâmetros, documenta-os e os testa com dados realistas.

Plano de cutover: data de corte, congelamento de dados, rollback – sem surpresas

O cutover é um projeto por si. Um bom plano de cutover descreve não só „quando mudar“, mas também medidas de proteção:

• Congelamento de dados: a partir de quando o sistema legado deixa de aceitar registos? Existem processos de contingência?
• Import final: quanto tempo dura realisticamente? (dry-runs fornecem números.)
• Validação: que checks devem estar verdes antes da liberação (counts, somas, amostras, relatórios funcionais)?
• Rollback: quando abortar e como proceder depois?
• Comunicação: quem autoriza? quem está disponível na sala de crise?

No Mittelstand o „rollback“ costuma ser mais crítico do ponto de vista organizacional do que técnico. Por isso a migração deve ser preparada para que o cutover não seja um experimento, mas um procedimento ensaiado.

Após a migração: base para REST, serviços e multiplataforma

Quando MariaDB estiver estável e a substituição da BDE for bem executada, surgem novas opções: APIs REST para sistemas externos, processamento background como serviços Windows ou Linux, desacoplamento de UI e lógica de negócio e, prospectivamente, clientes multiplataforma. Um passo frequente a seguir é extrair a lógica de negócio do desktop para atender integrações (ERP/DMS/CRM) e portais de forma controlada.

Importante: um servidor REST não é uma „camada adicional“, mas uma decisão arquitetural. Quem já consolidou acesso a dados, validações e permissões em services/repositories consegue desenvolver APIs robustas de forma muito mais simples.

Checklist prático: o que esclarecer antes do início do projeto

• Quais módulos são criticos para o negócio e devem funcionar sem falha no dia do cutover?
• Como são os volumes reais de dados (tamanhos de tabelas, crescimento, conceitos de arquivo)?
• Quais relatórios devem ser idênticos 1:1 e quais podem ser melhorados?
• Que integrações dependem do sistema (exportações de ficheiro, ODBC, Office, caminhos de impressão)?
• Existe capacidade multi-tenant e, se sim, como ela está representada hoje?
• Quais requisitos operacionais se aplicam (janela de backup, tempo de restauração, privilégios, auditoria)?

Esses esclarecimentos não são burocracia, mas evitam que uma migração fique „tecnicamente concluída“ sem ser aceite funcionalmente.

Conclusão: migrar controladamente é tornar riscos previsíveis

Migrar Paradox e BDE para MariaDB de forma controlada significa modernizar a aplicação como um sistema global: modelo de dados, SQL, transações, conjuntos de caracteres, camada de acesso e processos operacionais. Quem trata a mudança como um mero export recebe frequentemente exatamente os problemas que queria eliminar – só que agora num servidor diferente.

Um procedimento por etapas com import reproduzível, mapeamento de campos bem definido, validação precoce e uma substituição clara da BDE (por ex. via FireDAC) cria ao contrário uma base estável: para operação multiusuário, integrações, serviços e para os próximos passos da Delphi Modernisierung.

Se pretende planear a sua migração com segurança funcional e sem interrupção de operação, discutimos com prazer ponto de partida, riscos e um plano de etapas realista: https://net-base-software-gmbh.de/kontakt/