Контролируемая миграция Paradox и BDE в MariaDB

Многие Delphi-специализированные приложения были созданы с использованием таблиц Paradox и Borland Database Engine (BDE), поскольку это тогда был прагматичный стандарт: локально, быстро готово к работе, малая инфраструктура. На практике эти системы часто работают в продуктиве и по сей день — включая отчётность, печать этикеток, импорт/экспорт, пакетные задания, исторические таблицы и специфическую логику, которая за годы «встроилась» в доступ к данным. Именно поэтому миграция — это не просто экспорт данных, а контролируемая реконструкция: модель данных, поведение SQL, побочные эффекты в коде и эксплуатационные процессы должны рассматриваться совместно.

MariaDB часто является хорошим выбором в качестве целевой платформы, когда требуется надёжная многопользовательская эксплуатация, корректные транзакции, централизованные бэкапы, репликация, чёткое управление правами и возможность подключения веб‑порталов, сервисов или REST-API. Задачей обычно не является установка СУБД — реальная трудоёмкость сосредоточена в безопасном пути миграции: как корректно перенести таблицы, индексы, первичные ключи, наборы символов, поля дат, «пустые» значения и референциальные связи, чтобы бизнес‑логика в рабочей системе не нарушилась?

В этой статье описан проверенный подход для контролируемой миграции Paradox и BDE в MariaDB: технически обоснованно, поэтапно и с фокусом на стабильность. Цель — создать прочную основу для дальнейших шагов модернизации — например, замена BDE, переход на замену BDE с нативным подключением, чёткая Layer-3 архитектура, REST-серверы и кросс‑платформенные клиенты.

Почему миграция Paradox/BDE — это больше, чем смена СУБД

Paradox как формат файлов и BDE как слой доступа образуют целостную систему с особенностями, которые не стоит воспроизводить 1:1 в MariaDB. Типичные симптомы в повседневной эксплуатации:

• Непрозрачные зависимости: SQL‑запросы разбросаны по компонентам (формы, DataModules, отчёты, динамические строковые SQL), часто без центральной политики управления.
• Поведение «по ощущению»: Некоторые фильтры, сортировки или джойны работают случайно, потому что Paradox/BDE терпимы или выполняют неявные приведения типов.
• Ограничения многопользовательского режима: файловые блокировки, падение производительности по сети, проблемы с блокировками при росте объёмов данных.
• Риски сопровождения: зависимости от BDE, старые драйверы, сложный деплой на современных версиях Windows, вопросы 64‑бит/ARM64.

Контролируемая миграция рассматривает эти пункты не как побочный эффект, а как целевые критерии. MariaDB в этом контексте становится не просто «новой базой», а возможностью разнести слой доступа к данным, повысить предметную целостность и обеспечить пригодность к интеграции.

Целевое представление: MariaDB как стабильная основа для десктопа, сервисов и порталов

Практическая цель для B2B‑приложений обычно строится из трёх уровней:

• База данных (MariaDB): согласованное хранение данных, индексы, ограничения, транзакции, пользователи/роли, бэкапы.
• Предметная логика (сервер/сервисы): валидации, рабочие процессы, импортеры, планировщики, интерфейсы. Опционально как REST-сервер, Windows- или Linux‑сервисы.
• Клиенты (VCL/FMX/Web): интерфейсы, отчёты, офлайн‑части, интеграции. Идеально — с чёткими контрактами на предметную логику.

В зависимости от исходной ситуации не всё нужно реализовывать сразу. Но миграция должна планироваться так, чтобы не закрывать путь к чистой архитектуре. Тот, кто сегодня просто копирует таблицы и завтра вновь „прямо“ из каждой формы пишет в БД, получит MariaDB, но риски останутся.

Инвентаризация: что действительно нужно мигрировать

Начинается всё с инвентаризации, которая выходит за рамки вопроса «сколько таблиц». В проектах Paradox/BDE типично, что база данных — лишь часть правды. Важные моменты:

1) Таблицы, индексы, «псевдо‑ключи»

Часто отсутствуют реальные первичные ключи. Вместо этого используются комбинации полей, порядковые номера без явных ограничений или «ключевые» поля, поддерживаемые приложением. В MariaDB это нужно превращать в однозначные, надёжные ключи — иначе транзакции и референциальная целостность будут работать лишь частично.

2) Запросы, динамические SQL‑фрагменты, отчёты

BDE в зависимости от компонента использует разные SQL‑диалекты и допускает «креативные» выражения. Компоненты отчётности (включая старые) часто содержат собственные определения SQL. Миграция должна найти эти источники и классифицировать их: критичные ядровые запросы, редко используемые отчёты, специализированные импорты.

3) Наборы символов и спецсимволы (Umlaute, ISO/ANSI, Unicode)

Многие Paradox‑приложения исторически базировались на ANSI. Если Delphi‑приложение само в какой‑то момент перевели на Unicode, возникают смешанные состояния: данные в старой кодировке, UI — Unicode, экспорты ожидают Windows‑1252. MariaDB должна получить однозначную стратегию (типично utf8mb4), включая аккуратную конвертацию и тестирование на «невидимые» ошибки (сравнения, сортировка, Trim/Pad, спецсимволы).

4) „Пустые“ значения, логика NULL и поля дат

Paradox/BDE знают разные особые случаи: пустые строки вместо NULL, нулевые даты, «пустые» метки времени, значения по умолчанию, устанавливаемые в UI. MariaDB строго различает NULL и пустую строку. Это влияет на WHERE‑условия, агрегаты и расчёты. Эти различия нужно оценивать по каждой таблице/полю.

5) Побочные артефакты: временные таблицы сессии, локальная конфигурация, кэш

В Paradox‑структуре часто есть локальные таблицы для промежуточных результатов, буферы экспорта, пользовательские макеты или параметры. Что‑то должно оставаться локальным (например, макеты UI), а что‑то — централизованным (например, рабочие операции, статусы, логи). Миграция — это шанс чётко разделить эти категории.

Подводные камни Paradox/BDE: типичные технические различия

Чтобы сделать миграцию предсказуемой, имеет смысл явно адресовать повторяющиеся различия.

SQL‑диалект и операторы

SQL Paradox/BDE не идентичен MySQL/MariaDB. Различия проявляются в функциях даты, строковых функциях, внешних джойнах (исторически), логике Like/масок и в неявных приведениях типов. Контролируемый подход заменяет «вроде бы работает» на чёткие правила: какие выражения портируются, какие переписываются заново, какие инкапсулируются во Views/Stored Procedures (если это уместно).

Сортировка и collation

В Paradox порядок сортировки и чувствительность к регистру часто отличаются от MariaDB, особенно по умолчанию для умляутов. В MariaDB за сравнения и сортировку отвечает collation (например, utf8mb4_german2_ci против utf8mb4_unicode_ci). Это не академический вопрос: оно влияет на дедупликацию, функции поиска и поведение уникальных ограничений.

Автоинкремент и номерные ряды

В Paradox есть поля с автоинкрементом, но приложения часто используют собственные номерные ряды (номера документов, номера заказов) с особой логикой. В MariaDB следует чётко разделить:

• Технический первичный ключ: AUTO_INCREMENT (или UUID, в зависимости от архитектуры) для связей.
• Предметный номер: отдельный номерной ряд с транзакционной защитой, при необходимости по клиенту/периоду.

Кто пытается использовать предметный номер как технический ключ, позже столкнётся с дорогостоящими переделками.

Блокировки и транзакции

Переход от файлового доступа к полноценному серверу — это выигрыш, но он меняет поведение. В MariaDB транзакции (InnoDB) — центральный механизм. Нужно решить, где границы транзакций: на диалог, на операцию сохранения, на пакет. Особое внимание: долгие транзакции и «режим редактирования» на минутные интервалы распространены в Paradox‑мира, но на сервере критичны (блокировки, дедлоки, лаги репликации). Часто часть миграции — адаптация рабочей практики или UI.

Модель работ: контролируемая поэтапная миграция вместо Big Bang

В B2B‑среде эксплуатационная стабильность зачастую важнее быстрого «переключения». Поэтапный путь миграции снижает риск, поскольку предметная область и ИТ могут итеративно проводить валидацию.

Этап 1: перенос модели данных с маппингом, без изменения кода

На первом шаге строится схема MariaDB, которая отражает структуру Paradox — но уже с целевыми принципами: первичные ключи, индексы, адекватные типы данных, utf8mb4, InnoDB. Параллельно создаётся воспроизводимый процесс импорта (скрипты/инструменты), который можно запускать повторно. Важна повторяемость, поскольку миграция редко бывает «готова» с первого раза.

Ожидаемые результаты этой фазы обычно включают:

• Определение схемы (DDL) версионированное (например, в Git)
• Список маппинга полей (Paradox → MariaDB) с правилами конвертации
• Процедура импорта с логированием (число записей, ошибки, выбросы)
• Первые валидационные отчёты (counts, суммы, контрольные суммы)

Этап 2: замена BDE в доступе к данным (например, с помощью FireDAC)

Ключевой шаг модернизации — отделение от BDE. В Delphi‑проектах BDE-Ablosung mit nativer Anbindung зарекомендовал себя как путь, потому что даёт современные драйверы, транзакции, привязку параметров и единые компоненты для разных SQL‑бэкендов. Главное — не просто убрать BDE, а то, как будет выглядеть код после: централизованный доступ к данным, чёткая обработка ошибок, корректные параметры вместо конкатенации строк.

Типичные задачи этой фазы:

• Замена TTable/TQuery на FireDAC‑Queries и DataSets
• Введение слоя доступа к данным (DAL) как основы для последующей Layer-3 архитектуры
• Стандартизация областей транзакций (Commit/Rollback)
• Ревизия SQL: адаптация диалекта, параметры, пагинация, джойны

Если ваше приложение должно быть модернизировано в долгосрочной перспективе, этот шаг часто важнее чистой миграции данных. Он даёт техническую свободу для 64‑бит, современных версий Windows и аккуратных CI/CD‑цепочек.

Этап 3: параллельная эксплуатация и предметная приёмка без разрыва сервиса

Для критичных систем имеет смысл параллельная эксплуатация: MariaDB разворачивается и циклически (или инкрементально) наполняется, в то время как старая система продолжает работать. Это даёт возможность предметной области сравнивать отчёты, выявлять крайние случаи и тестировать новую платформу под нагрузкой. Параллельный режим можно реализовать по‑разному:

• реплика только для чтения для подготовки отчётности/BI
• «Dual Write» в определённых областях (только если это надёжно контролируется)
• статическая миграция на указанный момент с несколькими сухими прогонками и чётким чек‑листом для Cutover

Важно не усложнять: Dual‑Write звучит привлекательно, но чреват ошибками, если предметная логика не центализована. Часто более экономичен повторяемый статический перенос с хорошей валидацией.

Этап 4: оптимизация, целостность, производительность, операционные процессы

После Cutover начинается фаза, в которой MariaDB должна показать свои преимущества: референциальная целостность, производительные индексы, аккуратные права, мониторинг, тесты восстановления. Здесь обычно проявляются «настоящие» производственные нагрузки: долгие отчёты, плохо индексированные поисковые формы, пакетные обновления. Контролируемая миграция заранее планирует эту фазу, а не оставляет её как незапланированную доработку.

Типы данных и маппинг: из Paradox в MariaDB без потери информации

Маппинг полей — это сердце миграции. Типичные соответствия (упрощённо):

• Alpha / Memo: VARCHAR/TEXT (с utf8mb4), проверка длины и правила Trim
• Number: INT/BIGINT/DECIMAL в зависимости от диапазона значений; осторожность с неявными десятичными частями
• Date/Time: DATE/DATETIME/TIMESTAMP; чёткие правила для «0‑даты» или NULL
• Logical: BOOLEAN или TINYINT(1) с однозначной семантикой
• Currency: DECIMAL(…,2/4) вместо Float, чтобы избежать ошибок округления

Важно не только переводить типы, но и зафиксировать предметные правила: может ли поле быть NULL? Какие значения по умолчанию предметно корректны? Какие комбинации должны быть уникальными? На основе этого определяются ограничения и индексы. Эти правила в Paradox/BDE‑системах часто были неявны в UI или в коде — в MariaDB их, где это целесообразно, следует сделать явными.

Целостность: первичные ключи, внешние ключи и уникальные индексы

Многие legacy‑БД работают годами без референциальной целостности — до тех пор, пока не добавятся интеграции, порталы или параллельные процессы. Тогда качество данных становится ограничивающим фактором. В MariaDB можно использовать Foreign Keys, Unique Constraints и CHECK‑ограничения (в зависимости от версии/движка), чтобы обнаруживать ошибки данных на ранних стадиях.

Практичный путь — вводить целостность поэтапно:

• Сначала первичные ключи и уникальные индексы для ключевых сущностей (клиенты, артикула, документы)
• Затем внешние ключи в стабильных областях
• Для «исторических» таблиц с мусорными данными: сначала очистка, затем ограничения

Это снижает риск срыва Cutover из‑за исторических артефактов и в то же время заметно улучшает общую ситуацию.

Производительность на практике: что меняется с MariaDB

Системы Paradox/BDE часто оптимизированы под «файловую» скорость: локальные индексы, быстрый доступ к таблицам, много клиентской фильтрации. С MariaDB объём работы смещается на сервер. Это правильно, но требует чистой стратегии SQL и индексов.

Типичные проблемы производительности

• SELECT * из больших таблиц, потому что раньше «локально» это было достаточно быстро
• Клиентская фильтрация вместо серверных WHERE‑условий
• Отсутствие составных индексов для полей поисковых форм (например, мандант + статус + дата)
• LIKE ‚%text%‘ без подходящей стратегии полнотекстового поиска

Измеримое улучшение вместо «по ощущению»

Контролируемая миграция рано вводит точки измерения: Slow Query Log, Explain‑анализы, воспроизводимые нагрузочные тесты. Это особенно важно, если после миграции планируются дополнительные компоненты, например REST‑сервер или клиентский портал, который вводит новые шаблоны доступа (много мелких запросов, пагинация, поисковые эндпоинты).

Delphi‑специфика: замена BDE, FireDAC и чистые слои доступа

В Delphi‑проектах техническая модернизация тесно связана с доступом к данным. BDE — это не просто «драйвер», а целый стиль доступа (TTable, записьная модель, навигация, локальные фильтры). Миграция в MariaDB — удачный момент для консолидации доступа.

От «DataSets везде» к контролируемому доступу к данным

Во многих приложениях в каждой форме свои запросы. Это плохо масштабируется по предметности и безопасности. Эффективен переход в сторону:

• централизованных классов репозиториев/сервисов для ключевых сущностей
• единых механизмов обработки ошибок и транзакций
• параметризованных запросов (предотвращение SQL‑инъекций, использование кеширования планов)
• настраиваемых пулов подключений или менеджмента соединений для сервисов

Это закладывает основу для Layer-3 архитектуры, где UI, предметная логика и персистентность чётко разделены. Это помогает не только при смене СУБД, но и при дальнейшем развитии в сторону REST‑серверов или фоновых служб.

Подключение MariaDB через FireDAC: что обычно нужно согласовать

В проектах повторяются одни и те же вопросы: вариант драйвера (MySQL/MariaDB), опции SSL, настройки временной зоны и формата даты/времени, Unicode‑параметры. Это не детали, так как они прямо влияют на согласованность данных (дата/время), сортировку и эксплуатационную безопасность (TLS). Контролируемая миграция фиксирует эти параметры, документирует их и тестирует на реалистичных данных.

План Cutover: срок, заморозка данных, откат — без сюрпризов

Cutover — это отдельный проект. Хороший план Cutover описывает не только «когда переключать», но и меры защиты:

• Заморозка данных: с какого момента в старой системе больше не вносятся данные? Есть ли аварийные процессы?
• Финальный импорт: сколько он реально займёт? (сухие прогонки дают оценки.)
• Валидация: какие проверки должны быть зелёными перед выпуском (counts, суммы, выборочные проверки, предметные отчёты)?
• Откат: в каких случаях прерываем и каковы дальнейшие шаги?
• Коммуникация: кто даёт утверждение? кто доступен в War Room?

В сегменте Mittelstand откат часто критичен не столько технически, сколько организационно. Поэтому миграция должна быть подготовлена так, чтобы Cutover не был экспериментом, а отработанным сценарием.

После миграции: база для REST, сервисов и мультиплатформенности

Когда MariaDB стабильно работает и замена BDE выполнена аккуратно, открываются новые возможности: REST‑API для внешних систем, фоновые процессы как Windows‑ или Linux‑сервисы, разделение UI и предметной логики и в перспективе мультиплатформенные клиенты. Часто следующим шагом становится вынос предметной логики из десктопа, чтобы управляемо обслуживать интеграции (ERP/DMS/CRM) и порталы.

Важно: REST‑сервер — это не «ещё один слой», а архитектурное решение. Тот, кто заранее центрировал доступ к данным, валидации и права в сервисах/репозиториях, сможет значительно проще разработать надёжные API.

Практический чек‑лист: что следует прояснить до старта проекта

• Какие модули критичны для бизнеса и должны быть исправно доступны в день Cutover?
• Какие реальные объёмы данных (размеры таблиц, рост, концепции архивирования)?
• Какие отчёты должны быть идентичны 1:1, какие могут быть улучшены?
• Какие интеграции завязаны на систему (файловые экспорты, ODBC, Office, цепочки печати)?
• Есть ли поддержка нескольких мандантов, и если да — как это сейчас реализовано?
• Какие эксплуатационные требования применимы (окно бэкапа, время восстановления, права, аудит)?

Эти прояснения — не бюрократия, а средство предотвратить ситуацию, когда миграция «технически завершена», но предметно не принята.

Вывод: контролируемая миграция — значит делать риски предсказуемыми

Контролируемая миграция Paradox и BDE в MariaDB означает модернизацию приложения как целостной системы: модель данных, SQL, транзакции, наборы символов, слой доступа и операционные процессы. Кто рассматривает переход как чистый экспорт, получает те же проблемы, от которых хотел избавиться — но уже на новом сервере.

Поэтапный подход с воспроизводимым импортом, аккуратным маппингом полей, ранней валидацией и чёткой заменой BDE (например, через FireDAC) создаёт стабильную базу: для многопользовательского режима, интеграций, сервисов и следующих шагов Delphi Modernisierung.

Если вы хотите спланировать миграцию надёжно и выполнить её без разрыва сервисов, мы готовы обсудить исходную ситуацию, риски и реалистичный поэтапный план: https://net-base-software-gmbh.de/kontakt/