Migración controlada de Paradox y BDE a MariaDB

Muchas aplicaciones sectoriales de Delphi se crearon con tablas Paradox y la Borland Database Engine (BDE), porque en su momento fue un estándar pragmático: local, rápido para arrancar, con poca infraestructura. En la práctica, estos sistemas suelen seguir operativos hoy en día —incluyendo reporting, impresión de etiquetas, import/export, tareas por lotes, tablas históricas y lógica especial que se ha «colado» en el acceso a datos a lo largo de años. Precisamente por eso una migración no es solo exportar datos, sino una reconstrucción controlada: modelo de datos, comportamiento SQL, efectos secundarios en el código y procesos operativos deben considerarse conjuntamente.

MariaDB suele ser una muy buena opción como plataforma objetivo cuando se busca un funcionamiento robusto multiusuario, transacciones limpias, backups centrales, replicación, una gestión de permisos clara y la capacidad de conectar portales web, servicios o APIs REST. El reto rara vez es la instalación de la base de datos: el esfuerzo real está en la ruta de migración segura: ¿cómo se transfieren tablas, índices, claves primarias, conjuntos de caracteres, campos de fecha, valores “vacíos” y relaciones referenciales correctamente, sin que la lógica de negocio falle en producción?

Este artículo describe un enfoque probado para migrar Paradox y BDE a MariaDB de forma controlada: con base técnica, por etapas y con foco en la estabilidad. El objetivo es crear una base sólida para pasos de modernización posteriores —por ejemplo la sustitución de BDE, el cambio a una sustitución de BDE con conexión nativa, una arquitectura Layer-3 clara, servidores REST y clientes multiplataforma.

Por qué la migración Paradox/BDE es más que cambiar la base de datos

Paradox como formato de archivo y BDE como capa de acceso forman un sistema global con peculiaridades que no conviene replicar 1:1 en MariaDB. Síntomas típicos en el día a día son:

• Dependencias poco transparentes: las sentencias SQL están dispersas (formularios, DataModules, informes, SQL dinámico en cadenas), a menudo sin gobernanza central.
• Comportamiento «por intuición»: ciertos filtros, ordenaciones o joins funcionan por casualidad, porque Paradox/BDE es tolerante o convierte tipos implícitamente.
• Límites multiusuario: bloqueos basados en archivos, caídas de rendimiento en red, problemas de locking al aumentar el volumen de datos.
• Riesgos de mantenimiento: dependencias de BDE, drivers antiguos, despliegue complejo en versiones modernas de Windows, cuestiones 64‑bit/ARM64.

Una migración controlada no trata estos puntos como efectos colaterales, sino como criterios objetivo. MariaDB no debe ser solo la «nueva base de datos», sino la oportunidad para desacoplar la capa de acceso a datos, aumentar la integridad lógica y habilitar capacidades de integración.

Visión objetivo: MariaDB como base de datos estable para escritorio, servicios y portales

Una visión objetivo sensata para aplicaciones sectoriales B2B suele componerse de tres capas:

• Base de datos (MariaDB): almacenamiento consistente, índices, constraints, transacciones, usuarios/roles, backups.
• Lógica de negocio (Servidor/Servicios): validaciones, flujos, importadores, programador, interfaces. Opcionalmente como servidor REST, servicios Windows o servicios Linux.
• Clientes (VCL/FMX/Web): interfaces de usuario, informes, partes offline, integraciones. Idealmente con contratos claros hacia la lógica de negocio.

Dependiendo del punto de partida no todo debe implementarse de inmediato. Pero la migración debe planificarse de forma que no bloquee el camino hacia una arquitectura limpia. Quien hoy solo copie tablas y mañana vuelva a escribir «directamente» desde cada formulario en la base de datos habrá introducido MariaDB, pero habrá dejado intactos los riesgos reales.

Inventario: qué debe migrarse realmente

Al principio hay que hacer un inventario que vaya más allá de «cuántas tablas hay». En proyectos Paradox/BDE es habitual que la base de datos sea solo una parte de la verdad. Puntos importantes:

1) Tablas, índices, «pseudo‑claves»

Con frecuencia faltan claves primarias reales. En su lugar existen combinaciones de campos, números secuenciales sin constraints claros o campos «Key» que mantiene la aplicación. Para MariaDB deben convertirse en claves únicas y robustas; de lo contrario las transacciones y la integridad referencial serán de eficacia limitada.

2) Consultas, bloques SQL dinámicos, informes

BDE emplea distintos dialectos SQL según el componente y tolera sentencias «creativas». Los componentes de reporting (incluso los más antiguos) suelen incluir sus propias definiciones SQL. Una migración debe localizar y categorizar estas fuentes: consultas críticas, análisis raramente usados, importaciones especiales.

3) Conjunto de caracteres y caracteres especiales (umlauts, ISO/ANSI, Unicode)

Muchas aplicaciones Paradox son históricamente ANSI. Si la aplicación Delphi se migró internamente a Unicode en algún momento, se generan entornos mixtos: datos en un encoding antiguo, UI en Unicode, exportaciones esperando Windows‑1252. MariaDB debe recibir un concepto claro (típicamente utf8mb4), incluyendo conversión limpia y pruebas para detectar errores «invisibles» (comparaciones, ordenación, trim/pad, caracteres especiales).

4) Valores “vacíos”, lógica NULL y campos de fecha

Paradox/BDE conoce varios casos especiales: cadenas vacías en lugar de NULL, fechas 0, timestamps “vacíos”, valores por defecto que genera la UI. MariaDB distingue de forma estricta entre NULL y vacío. Eso afecta cláusulas WHERE, agregaciones y cálculos. Estas diferencias deben evaluarse por tabla/campo.

5) Artefactos accesorios: tablas de sesión, configuración local, caché

A menudo en la estructura Paradox hay tablas locales para resultados intermedios, buffers de exportación, diseños de usuario o parámetros. Parte de ello debe permanecer local (p. ej. layouts UI), otra parte debe centralizarse (p. ej. procesos de trabajo, estados, logs). La migración es una oportunidad para separar estas categorías de forma limpia.

Piedras de tropiezo en Paradox/BDE: diferencias técnicas típicas

Para que la migración sea planificable conviene abordar explícitamente las diferencias recurrentes.

Dialectos SQL y operadores

SQL de BDE/Paradox no es idéntico al SQL de MySQL/MariaDB. Aparecen diferencias, por ejemplo, en funciones de fecha, funciones de cadena, outer joins (históricos), lógica de Like/máscaras y conversiones implícitas de tipo. Un enfoque controlado reemplaza el «ya funciona» por reglas claras: ¿Qué sentencias se portan, cuáles se reescriben deliberadamente, cuáles se encapsulan en vistas/stored procedures (si procede)?

Ordenación y collation

En Paradox los órdenes y la sensibilidad a mayúsculas/minúsculas suelen diferir de MariaDB, en particular con diéresis. En MariaDB la collation (p. ej. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) determina comparación y ordenación. No es una cuestión académica: afecta deduplicación, funciones de búsqueda y el comportamiento de unique constraints.

Autoincrement y series de números

Paradox tiene campos autoincrementales, pero las aplicaciones suelen usar sus propios números de serie (número de documento, número de pedido) con lógica especial. En MariaDB conviene separar con claridad:

• Clave primaria técnica: AUTO_INCREMENT (o UUID, según la arquitectura) para relaciones.
• Número de negocio: serie propia con protección transaccional, posiblemente por cliente/periodo.

Quien intente abusar de un número de negocio como clave técnica se arriesga a costosas modificaciones posteriores.

Bloqueos y transacciones

El salto de acceso basado en archivos a un servidor real es una ganancia, pero cambia el comportamiento. En MariaDB las transacciones (InnoDB) son centrales. Hay que decidir dónde están los límites transaccionales: por diálogo, por operación de almacenamiento, por lote. Especialmente importante: en entornos Paradox es común el «modo edición» durante minutos; en servidor eso es crítico (locks, deadlocks, lag de replicación). A menudo una adaptación del flujo de trabajo o de la UI forma parte de la migración.

Modelo de trabajo: migración controlada por etapas en lugar de Big Bang

En entornos B2B la estabilidad operativa suele ser más importante que un corte rápido. Un camino de migración por etapas reduce el riesgo, porque el área de negocio y TI pueden validar de forma iterativa.

Etapa 1: transferencia del modelo de datos con mapping, sin reescribir código

En el primer paso se crea un esquema MariaDB que refleje la estructura Paradox —pero ya con principios objetivo: claves primarias, índices, tipos de datos adecuados, utf8mb4, InnoDB. En paralelo se desarrolla un proceso reproducible de importación (scripts/herramientas) que pueda ejecutarse varias veces si hace falta. La reproducibilidad es clave, porque la migración rara vez acaba en la primera ejecución.

Entregables típicos de esta etapa:

• Definición del esquema (DDL) versionada (p. ej. en Git)
• Lista de mapeo de campos (Paradox → MariaDB) con reglas de conversión
• Procedimiento de importación con registro (conteo de registros, errores, excepciones)
• Primeros informes de validación (counts, sumas, checksums)

Etapa 2: sustitución de BDE en el acceso a datos (p. ej. con FireDAC)

El verdadero paso de modernización es desacoplar BDE. En proyectos Delphi BDE-Ablosung mit nativer Anbindung es una vía probada, porque ofrece drivers modernos, transacciones, binding de parámetros y componentes uniformes para distintos backends SQL. Lo decisivo no es «quitar BDE», sino c&oacuten;mo queda el código después: acceso a datos centralizado, manejo de errores claro, parámetros limpios en lugar de concatenación de cadenas.

Tareas típicas en esta etapa:

• Reemplazar TTable/TQuery por FireDAC‑Queries y DataSets
• Introducir una capa de acceso a datos (DAL) como base para una futura arquitectura Layer-3
• Estandarizar los scopes transaccionales (Commit/Rollback)
• Revisión SQL: adaptación de dialecto, parámetros, paginación, joins

Si su aplicación se va a modernizar a largo plazo, este paso suele ser más importante que la sola migración de datos. Crea la libertad técnica para 64‑Bit, versiones modernas de Windows y pipelines de despliegue limpias.

Etapa 3: funcionamiento en paralelo y aceptación funcional sin interrupción operativa

Para sistemas críticos tiene sentido un funcionamiento en paralelo: se monta MariaDB y se rellena de forma cíclica (o incremental) mientras el sistema antiguo sigue en producción. Así el negocio puede comparar informes, identificar casos límite y probar la nueva plataforma bajo carga. El funcionamiento paralelo puede implementarse de varias formas:

• Réplicas en solo lectura para reporting/BI
• „Dual Write“ en áreas definidas (solo si está bien controlado)
• Migración en fecha fija con varios ensayos y una checklist clara de corte

Es importante no aumentar la complejidad innecesariamente: Dual‑Write parece atractivo pero es proclive a errores si la lógica de negocio no está centralizada. A menudo un proceso de corte repetible con buena validación resulta más económico.

Etapa 4: optimización, integridad, rendimiento, procesos operativos

Tras el cutover comienza la fase en la que MariaDB debe demostrar sus fortalezas: integridad referencial, índices eficientes, permisos claros, monitorización, pruebas de backup/restore. Aquí suelen hacerse visibles las cargas reales de producción: informes largos, máscaras de búsqueda mal indexadas, actualizaciones por lotes intensivas. Una migración controlada planifica explícitamente esta etapa en lugar de dejarla como trabajo imprevisto posterior.

Tipos de datos y mapeo: de Paradox a MariaDB sin pérdida de información

El mapeo de campos es el núcleo de la migración. Asignaciones típicas (simplificadas) son:

• Alpha / Memo: VARCHAR/TEXT (con utf8mb4), comprobaciones de longitud y reglas de trim
• Number: INT/BIGINT/DECIMAL según el rango; precaución con decimales implícitos
• Date/Time: DATE/DATETIME/TIMESTAMP; reglas claras para «fecha 0» o NULL
• Logical: BOOLEAN o TINYINT(1) con semántica inequívoca
• Currency: DECIMAL(…,2/4) en lugar de float para evitar errores de redondeo

Es importante no limitarse a traducir tipos, sino documentar también las reglas de negocio: ¿puede un campo ser NULL? ¿Qué valores por defecto son correctos funcionalmente? ¿Qué combinaciones deben ser únicas? De esas reglas derivan constraints e índices. Estas reglas solían estar implícitas en UI o código en el sistema Paradox/BDE; en MariaDB deberían hacerse explícitas donde tenga sentido.

Integridad: llevar Primary Keys, Foreign Keys e índices únicos

Muchas bases legacy han funcionado años sin integridad referencial —hasta que aparecen integraciones, portales o procesos paralelos. En ese momento la calidad de datos se convierte en factor limitante. En MariaDB se pueden aplicar Foreign Keys, Unique Constraints y CHECKs (según versión/engine) para prevenir errores de datos de forma temprana.

Un enfoque práctico es introducir la integridad de forma escalonada:

• Primero Primary Keys e índices únicos en objetos núcleo (clientes, artículos, documentos)
• Después Foreign Keys en áreas estables
• Para tablas «históricas» con datos sucios: primero limpieza, luego constraints

Esto reduce el riesgo de que el cutover fracase por cargas heredadas y mejora la situación global de forma significativa.

Rendimiento en la práctica: qué cambia con MariaDB

Los sistemas Paradox/BDE suelen optimizarse para «velocidad de archivo»: índices locales, accesos rápidos a tablas, mucho filtrado en el cliente. Con MariaDB la carga se desplaza al servidor. Eso es positivo, pero exige estrategias limpias de SQL e índices.

Fallas típicas de rendimiento

• SELECT * en tablas grandes, porque antes «localmente» era suficientemente rápido
• Filtrado en el cliente en lugar de cláusulas WHERE en el servidor
• Falta de índices compuestos para máscaras de búsqueda (p. ej. Mandante + Estado + Fecha)
• LIKE ‚%texto%‘ sin una estrategia de texto completo adecuada

Mejoras medibles en lugar de «por intuición»

Una migración controlada establece puntos de medición desde el principio: Slow Query Log, análisis EXPLAIN, pruebas de carga reproducibles. Esto es especialmente importante si después de la migración se planean componentes adicionales, como un servidor REST o un portal de clientes que genere nuevos patrones de acceso (muchas peticiones pequeñas, paginación, endpoints de búsqueda).

Específico para Delphi: sustitución de BDE, FireDAC y capas de acceso limpias

En proyectos Delphi la modernización técnica está estrechamente ligada al acceso a datos. BDE no es solo «un driver», sino un estilo completo de acceso (TTable, basado en registros, navegación, filtros locales). Migrar a MariaDB es el momento adecuado para consolidar el acceso.

De «DataSets por todas partes» a acceso a datos controlado

Muchas aplicaciones tienen sus propias consultas en cada formulario. Eso escala mal desde el punto de vista funcional y de seguridad. Ha demostrado ser eficaz moverse hacia:

• Clases repository/service centrales para objetos núcleo
• Manejo uniforme de errores y transacciones
• Queries parametrizadas (evitar SQL Injection, aprovechar plan caching)
• Pool de conexiones configurable o gestión de conexiones para servicios

Así se crea una base para una arquitectura Layer-3, donde UI, lógica de negocio y persistencia están claramente separadas. Eso no solo ayuda en el cambio de base de datos, sino también en la evolución hacia un servidor REST o servicios en segundo plano.

Conexión a MariaDB con FireDAC: cuestiones habituales

En los proyectos surgen repetidamente las mismas preguntas: ¿qué variante de driver (MySQL/MariaDB), qué opciones SSL, qué ajustes de zona horaria y formato de fechas, qué settings Unicode? No son detalles pequeños, porque impactan directamente en la consistencia de datos (fecha/hora), ordenación y seguridad operativa (TLS). Una migración controlada fija estos parámetros, los documenta y los prueba con datos representativos.

Plan de corte: fecha de corte, congelación de datos, rollback — sin sorpresas

El cutover es un proyecto en sí mismo. Un buen plan de corte no solo indica «cuándo cambiar», sino también las medidas de protección:

• Congelación de datos: ¿a partir de cuándo no se introducirán más datos en el sistema antiguo? ¿Existen procesos de emergencia?
• Importación final: ¿cuánto tiempo dura realmente? (los ensayos aportan cifras).
• Validación: ¿qué comprobaciones deben estar en verde antes de la liberación (conteos, sumas, muestreos, informes funcionales)?
• Rollback: ¿en qué punto se cancela y cómo se procede entonces?
• Comunicación: ¿quién autoriza el cambio? ¿quién está disponible en el war room?

En el Mittelstand un «rollback» suele ser más crítico por motivos organizativos que técnicos. Por eso la migración debe prepararse de forma que el cutover no sea un experimento, sino un flujo ensayado.

Después de la migración: base para REST, servicios y multiplataforma

Cuando MariaDB funciona estable y la sustitución de BDE se ha realizado con limpieza, se abren nuevas opciones: APIs REST para sistemas externos, procesamiento en segundo plano como servicios Windows o Linux, desacoplamiento de UI y lógica de negocio y, a futuro, clientes multiplataforma. Con frecuencia el siguiente paso es extraer la lógica de negocio del desktop para atender integraciones (ERP/DMS/CRM) y portales de forma controlada.

Es importante: un servidor REST no es una «capa adicional», sino una decisión arquitectural. Quien ya haya consolidado el acceso a datos, las validaciones y los permisos en servicios/repositories podrá desarrollar APIs robustas con mucha menos fricción.

Lista de verificación práctica: qué aclarar antes de iniciar el proyecto

• ¿Qué módulos son críticos para el negocio y deben funcionar con seguridad el día del corte?
• ¿Cuál es el volumen real de datos (tamaño de tablas, crecimiento, conceptos de archivado)?
• ¿Qué informes deben ser idénticos 1:1 y cuáles pueden mejorarse?
• ¿Qué integraciones dependen del sistema (exportaciones de archivos, ODBC, Office, flujos de impresión)?
• ¿Existe multi‑tenancy y, en caso afirmativo, cómo está representada hoy?
• ¿Qué requisitos operativos aplican (ventana de backup, tiempo de restore, permisos, auditoría)?

Estas aclaraciones no son burocracia: evitan que una migración quede «técnicamente terminada» pero sin aceptación funcional.

Conclusión: migrar de forma controlada significa hacer los riesgos manejables

Migrar Paradox y BDE a MariaDB de forma controlada implica modernizar la aplicación como sistema completo: modelo de datos, SQL, transacciones, conjuntos de caracteres, capa de acceso y procesos operativos. Quien vea el cambio como un simple export recibe con frecuencia exactamente los problemas que quería dejar atrás —solo que ahora en un servidor nuevo.

Un enfoque por etapas con importación reproducible, mapeo de campos claro, validación temprana y una sustitución bien definida de BDE (p. ej. mediante FireDAC) crea, en cambio, una base estable: para operación multiusuario, integraciones, servicios y los siguientes pasos de la modernización Delphi.

Si desea planificar su migración con seguridad funcional y sin interrupciones operativas, hablamos con gusto de la situación inicial, los riesgos y un plan de etapas realista: https://net-base-software-gmbh.de/kontakt/