Контрольована міграція Paradox та BDE на MariaDB

Багато Delphi-галузевих застосунків були створені з Paradox-таблицями та Borland Database Engine (BDE), оскільки це тоді був прагматичний стандарт: локально, швидко готово до роботи, мінімум інфраструктури. На практиці ці системи часто працюють продуктивно й досі — включно з reporting, друком етикеток, імпортом/експортом, batch-завданнями, історичними таблицями та спеціальною логікою, яка роками «в’їлася» у доступ до даних. Саме тому міграція — це не просто експорт даних, а контрольована перебудова: модель даних, поведінка SQL, побічні ефекти в коді та операційні процеси потрібно розглядати комплексно.

MariaDB часто є дуже хорошим вибором як цільова платформа, коли йдеться про надійну мультикористувацьку експлуатацію, коректні транзакції, централізовані бекапи, реплікацію, чітке управління правами та підключення для веб-порталів, сервісів або REST-API. Виклик рідко полягає в самій інсталяції бази даних — основні витрати приховані в безпечному шляху міграції: як коректно перенести таблиці, індекси, первинні ключі, набори символів, поля дат, «порожні» значення та референтні зв’язки, щоб бізнес-логіка в робочому середовищі не зламалася?

Цей матеріал описує перевірений підхід до контрольованої міграції з Paradox та BDE на MariaDB: технічно обґрунтовано, поетапно та з фокусом на стабільності. Мета — створити міцну основу для подальших кроків модернізації — наприклад BDE-виведення з експлуатації, перехід на BDE-Ablösung mit nativer Anbindung, чітку Layer-3 Architektur, REST-Server та платформо-незалежні клієнти.

Чому міграція Paradox/BDE — це більше, ніж заміна СУБД

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

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

Контрольована міграція розглядає ці пункти не як побічні ефекти, а як критерії успіху. MariaDB у такому підході стає не просто «новою базою», а можливістю розв’язати шар доступу до даних, підвищити предметну цілісність і забезпечити інтеграційну придатність.

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

Практичне цільове уявлення для B2B-галузевих застосунків зазвичай складається з трьох рівнів:

• База даних (MariaDB): консистентне зберігання даних, індекси, constraints, транзакції, користувачі/ролі, бекапи.
• Предметна логіка (Server/Services): валідації, робочі потоки, імпортери, scheduler, інтерфейси. Опціонально як REST-Server, Windows- або Linux-Services.
• Клієнти (VCL/FMX/Web): інтерфейси, звіти, офлайн-частини, інтеграції. Ідеально — із чіткими контрактами на предметну логіку.

Залежно від вихідної ситуації не все має бути реалізовано одразу. Але міграція повинна плануватися так, щоб не перекривати шлях до чистої архітектури. Хто сьогодні просто копіює таблиці і завтра знову «прямо» з кожної форми пише в базу, той хоч і ввів MariaDB, але справжні ризики залишаться.

Інвентаризація: що дійсно треба мігрувати

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

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

Часто відсутні справжні Primary Keys. Натомість існують комбінації полів, порядкові номери без однозначного constraint або «Key»-поля, що підтримуються в додатку. Для 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, 0‑дати, «порожні» timestamps, значення за замовчуванням, що формуються в UI. MariaDB суворо розрізняє NULL і порожнє значення. Це впливає на WHERE‑клаузи, агрегати та обчислення. Ці відмінності треба оцінити для кожної таблиці/поля.

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

У структурі Paradox часто є локальні таблиці для проміжних результатів, буферів експорту, макетів користувача або параметрів. Частина має залишатися локально (наприклад макети UI), інше слід централізувати (наприклад робочі процеси, статуси, логи). Міграція — це нагода чітко розмежувати ці категорії.

Підводні камені Paradox/BDE: типовi технічні відмінності

Щоб зробити міграцію прогнозованою, варто явно адресувати повторювані відмінності.

SQL-діалект і оператори

BDE/Paradox-SQL не тотожний MySQL/MariaDB-SQL. Відмінності проявляються зокрема в функціях для дат, строкових функціях, Outer Joins (історично), логіці Like/масок та неявних перетвореннях типів. Контрольований підхід замінює «й так працює» чіткими правилами: які вирази переносяться, які переписуються свідомо, які інкапсулюються у VIEW/Stored Procedure (якщо це має сенс)?

Сортування та Collation

У Paradox порядок сортування і регістрозалежність часто відрізняються від MariaDB, особливо щодо умляутів. У MariaDB за порівнянням і сортуванням відповідає collation (наприклад utf8mb4_german2_ci vs. utf8mb4_unicode_ci). Це не академічне питання: воно впливає на дедуплікацію, пошукові функції та поведінку унікальних обмежень.

Autoincrement та номерні ряди

Paradox має поля з автозбільшенням, але додатки часто використовують власні номерні ряди (номери документів, номер замовлення) зі спеціальною логікою. У MariaDB слід чітко розмежувати:

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

Хто намагається використовувати предметний номер як технічний ключ, ризикує дорогою переробкою надалі.

Блокування і транзакції

Перехід від файлового доступу до справжнього серверного доступу — це виграш, але він змінює поведінку. У MariaDB транзакції (InnoDB) центральні. Треба вирішити, де проходять межі транзакцій: на діалозі, при збереженні, у batch. Особливо важливо: довгі транзакції та режим редагування протягом хвилин поширені в Paradox-середовищах, але на сервері вони критичні (блокування, deadlock, реплікаційне відставання). Часто частиною міграції стає адаптація робочих процесів або UI.

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

У B2B-середовищах стабільність експлуатації часто важливіша за швидкий перевід. Поступовий шлях міграції зменшує ризик, бо бізнес і IT можуть ітеративно валідувати результати.

Етап 1: перенесення моделі даних з мапінгом, без перебудови коду

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

Deliverables цього етапу зазвичай:

• Версіонована дефініція схеми (DDL) (напр., у Git)
• Список мапінгу полів (Paradox → MariaDB) з правилами конвертації
• Процедура імпорту з логуванням (кількість записів, помилки, викиди)
• Перші валідаційні звіти (counts, суми, контрольні суми)

Етап 2: BDE-виведення з доступу на рівні доступу до даних (напр. з FireDAC)

Справжній крок модернізації — це розв’язання від BDE. У Delphi-проектах BDE-Ablosung mit nativer Anbindung є перевіреним шляхом, бо дає сучасні драйвери, транзакції, прив’язку параметрів та уніфіковані компоненти для різних SQL-бекендів. Важливо не сам факт «BDE назовні», а те, як виглядає код потім: центральний доступ до даних, чітка обробка помилок, коректні параметри замість рядкових конкатенацій.

Типові задачі цього етапу:

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

Якщо ваш застосунок планується до довготривалої модернізації, цей крок часто важливіший за саму міграцію даних. Він забезпечує технічну свободу для 64‑битних рішень, сучасних версій Windows та чистих pipeline розгортання.

Етап 3: паралельна експлуатація та предметна прийомка без перебоїв

Для критичних систем доцільний паралельний режим: MariaDB розгортається і циклічно (або інкрементально) наповнюється, поки старе середовище продовжує працювати. Це дозволяє бізнесу порівняти звіти, виявити крайові випадки та протестувати нову платформу під навантаженням. Паралельна експлуатація може бути реалізована по-різному:

• Read-only-репліка для підготовки reporting/BI
• «Dual Write» у визначених підсистемах (тільки якщо добре підконтрольний)
• Міграція на визначену дату зі кількома прогоновими тестами та чітким cutover-чеклістом

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

Етап 4: оптимізація, цілісність, продуктивність, операційні процеси

Після cutover починається фаза, у якій MariaDB має проявити свої сильні сторони: референтна цілісність, ефективні індекси, чисті права, моніторинг, тести backup/restore. Тут зазвичай виявляються «справжні» виробничі навантаження: довгі звіти, погано індексовані пошукові маски, batch-оновлення. Контрольована міграція передбачає цю фазу явно, а не як незаплановану доробку.

Типи даних і мапінг: від 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? Які дефолтні значення предметно коректні? Які комбінації мають бути унікальними? Звідси випливають constraints та індекси. Ці правила в Paradox/BDE-системах часто були неявно закладені в UI або коді — у MariaDB їх, де доцільно, слід зробити явними.

Цілісність: Primary Keys, Foreign Keys та унікальні індекси

Багато legacy-баз десятиліттями працюють без референтної цілісності — поки не з’являються інтеграції, портали або паралельні процеси. Тоді якість даних стає критичним фактором. У MariaDB можна застосувати Foreign Keys, Unique Constraints і CHECK (залежно від версії/движка), щоб виявляти помилки на ранньому етапі.

Практичний шлях — поетапне введення цілісності:

• Спочатку Primary Keys і унікальні індекси на ключових об’єктах (клієнти, товари, документи)
• Потім Foreign Keys у стабільних ділянках
• Для «історичних» таблиць із забрудненими даними: спочатку очищення, потім constraints

Це знижує ризик, що cutover зірветься через історичні артефакти, і суттєво покращує загальний стан даних.

Продуктивність на практиці: що змінюється з MariaDB

Paradox/BDE-системи часто оптимізовані під «швидкість файлу»: локальні індекси, швидкий доступ до таблиць, багато фільтрації на клієнті. У MariaDB навантаження переноситься на сервер. Це добре, але вимагає акуратної стратегії SQL та індексів.

Типові пастки продуктивності

• SELECT * з великих таблиць, бо раніше «локально» було достатньо швидко
• Клієнтське фільтрування замість серверних WHERE-клауз
• Відсутність складених індексів для пошукових масок (наприклад Mandant + Status + Date)
• LIKE ‚%text%‘ без відповідної стратегії повнотекстового пошуку

Вимірювано покращувати, а не «за відчуттям»

Контрольована міграція рано встановлює точки вимірювання: Slow Query Log, Explain-аналізи, відтворювані навантажувальні тести. Це особливо важливо, якщо після міграції плануються додаткові компоненти, наприклад REST-Server або Kundenportal, що сформує інші шаблони доступу (багато дрібних запитів, пагінація, пошукові ендпоїнти).

Delphi-специфічно: виведення BDE, FireDAC і чисті шари доступу

У Delphi-проектах технічна модернізація тісно пов’язана з доступом до даних. BDE — це не просто «драйвер», а повний стиль доступу (TTable, робота з записами, навігація, локальні фільтри). Міграція на MariaDB — слушний момент, щоб консолідувати доступ.

Від «DataSets усюди» до контрольованого доступу до даних

У багатьох застосунках у кожній формі свої запити. Це погано масштабується з точки зору предметної логіки та безпеки. Випробуваною практикою є перехід у напрямі:

• Централізовані класи Repository/Service для ключових об’єктів
• Уніфікована обробка помилок та транзакцій
• Параметризовані запити (щоб уникнути SQL Injection, використовувати кешування планів)
• Налаштовувані connection-пули або управління з’єднаннями для сервісів

Це створює базу для Layer-3 архітектури, де UI, предметна логіка та персистентність чітко розділені. Це допомагає не лише при зміні СУБД, а й при подальшому розвитку в сторону REST-Server або бекґраунд-сервісів.

Підключення MariaDB через FireDAC: що типово треба узгодити

У проєктах постійно з’являються одні й ті самі питання: який варіант драйвера (MySQL/MariaDB), які опції SSL, які timezone- і налаштування дат, які Unicode‑параметри? Це не дрібниці, бо вони прямо впливають на консистентність даних (дата/час), сортування та робочу безпеку (TLS). Контрольована міграція фіксує ці параметри, документує їх і тестує на реалістичних даних.

Cutover-план: дата, заморожування даних, відкат — без сюрпризів

Cutover — це окремий проєкт. Хороший план cutover описує не лише «коли переключати», а й заходи захисту:

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

У сегменті SME відкат часто є не технічним, а організаційно критичним. Тому міграція має бути підготовлена так, щоб cutover не був експериментом, а відрепетированим сценарієм.

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

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

Важливий момент: REST-Server — це не «додатковий шар», а архітектурне рішення. Хто вже централізував доступ до даних, валідацію та права у сервісах/репозиторіях, зможе набагато простіше розробити стійкі API.

Практичний чекліст: що уточнити перед стартом проєкту

• Які модулі критичні для бізнесу і мають безперебійно працювати в день cutover?
• Які реальні обсяги даних (розміри таблиць, ріст, концепти архівації)?
• Які звіти мають бути 1:1 і які можуть бути покращені?
• Які інтеграції залежать від системи (файлові експорти, ODBC, Office, друкарські лінії)?
• Чи є багатомандантність, і якщо так — як вона сьогодні реалізована?
• Які операційні вимоги застосовуються (вікно бекапу, RTO/RPO, права, аудит)?

Ці уточнення не бюрократія, а запобіжний захід, щоб міграція була «технічно завершена», але також прийнята предметно.

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

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

Поетапний підхід з відтворюваним імпортом, чистим мапінгом полів, ранньою валідацією та чітким виведенням BDE (наприклад через FireDAC) створює стабільну основу: для мультикористувацької роботи, інтеграцій, сервісів і наступних кроків у Delphi Modernisierung.

Якщо ви хочете спланувати міграцію предметно та без перебоїв у роботі, ми готові обговорити вихідну ситуацію, ризики та реалістичний етапний план: https://net-base-software-gmbh.de/kontakt/