Paradox и BDE контролирано да мигрират към MariaDB

Много Delphi специализирани приложения са създадени върху Paradox-таблици и Borland Database Engine (BDE), защото това бе прагматичният стандарт: локално, бързо за пускане, с малко инфраструктура. На практика тези системи често работят продуктивно и до днес — включително отчетност, печат на етикети, импорт/експорт, batch-задачи, исторически таблици и специална логика, която се е „вграждала“ в достъпа до данни през годините. Затова миграцията не е само експортиране на данни, а контролирана реконструкция: модел на данните, SQL-поведение, странични ефекти в кода и оперативни процеси трябва да се разглеждат заедно.

MariaDB често е много добър избор като целева платформа, когато става дума за стабилна многопотребителска работа, коректни транзакции, централизирано архивиране, репликация, ясна система за права и възможност за свързване към уеб-портали, услуги или REST-API. Предизвикателството рядко е инсталацията на базата данни — съществените усилия са в сигурния миграционен път: как да се прехвърлят таблици, индекси, primary keys, кодировки, полета за дати, „празни“ стойности и референтни връзки правилно, без да се наруши бизнес-логиката в продуктивна среда?

Този материал описва изпитана процедура за контролирана миграция от Paradox и BDE към MariaDB: технически обосновано, поетапно и с фокус върху стабилността. Целта е носеща основа за последващи стъпки на модернизация — например BDE-отстраняване, миграция към BDE-Ablösung mit nativer Anbindung, ясна Layer-3 Architektur, REST-Server и платформа-неутрални клиенти.

Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel

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

• Intransparente Abhängigkeiten: SQL-изразите са разпръснати (Forms, DataModules, Reports, динамичен String-SQL), често без централно управление.
• Verhalten „nach Gefühl“: Някои филтри, сортирания или joins работят случайно, защото Paradox/BDE е толерантен или извършва имплицитни конверсии на типове.
• Mehrbenutzer-Grenzen: Заключвания на ниво файл, спад в производителността по мрежата, locking-проблеми при растящи обеми данни.
• Wartungsrisiken: Зависимости от BDE, остарели драйвери, трудно деплойване върху модерни Windows-версии, 64‑Bit/ARM64 въпроси.

Контролираната миграция не третира тези аспекти като странични ефекти, а ги дефинира като критерии за успех. MariaDB не е просто „нова база“, а възможност да се отвърже слоят за достъп до данни, да се повиши предметната цялост и да се създадат стандартизирани интерфейси.

Zielbild: MariaDB als stabile Datenbasis für Desktop, Services und Portale

Смисленото целево изображение за B2B-приложения обикновено включва три слоя:

• Datenbank (MariaDB): консистентно съхранение на данни, индекси, constraints, транзакции, потребители/роли, резервни копия.
• Fachlogik (Server/Services): валидaции, workflow-и, импортьори, scheduler, интерфейси. По избор като REST-Server, Windows- или Linux-Services.
• Clients (VCL/FMX/Web): потребителски интерфейси, отчети, офлайн-части, интеграции. Идеално с ясни контрактни граници към Fachlogik.

В зависимост от стартовата ситуация не е необходимо всичко да се реализира наведнъж. Миграцията трябва обаче да бъде планирана така, че да не блокира пътя към чиста архитектура. Който днес само копира таблици и утре отново пише „директно“ от всяка форма към базата, е въвел MariaDB, но истинските рискове остават.

Bestandsaufnahme: Was wirklich migriert werden muss

В началото стои инвентаризация, която надхвърля „колко таблици има“. В Paradox/BDE проекти е типично базата да е само част от истината. Важни точки:

1) Tabellen, Indizes, „Pseudo-Schlüssel“

Често липсват истински Primary Keys. Наличие са комбинации от полета, последователни номера без явен constraint или „ключови“ полета, поддържани от приложението. За MariaDB те трябва да станат еднозначни и устойчиви ключове — иначе транзакциите и референтната цялост ще имат ограничена ефективност.

2) Queries, dynamische SQL-Bausteine, Reports

BDE използва, в зависимост от компонента, различни SQL-диалекти и допуска „креативни“ изрази. Компонентите за отчетност (включително по-стари) често съдържат собствени SQL-дефиниции. Миграцията трябва да открие и категоризира тези източници: критични основни заявки, рядко използвани справки, специални импорти.

3) Zeichensatz und Sonderzeichen (Umlaute, ISO/ANSI, Unicode)

Много Paradox-приложения са исторически базирани на ANSI. Ако самото Delphi приложение някога е преминало към Unicode, възникват смесени състояния: данните са в старо кодиране, UI е Unicode, експорти очакват Windows-1252. MariaDB трябва да получи ясен концепт (типично utf8mb4), включително коректна конверсия и тестове за „невидими“ грешки (сравнения, сортиране, Trim/Pad, специални символи).

4) „Leere“ Werte, Null-Logik und Datumsfelder

Paradox/BDE познава различни специални случаи: празни низове вместо NULL, 0-данни, „празни“ timestamp-ове, default-стойности, които възникват в UI. MariaDB разграничaва строго NULL от празно. Това влияе на WHERE-клауза, агрегирания и изчисления. Разликите трябва да се оценят по таблица/поле.

5) Nebenartefakte: Session-Tabellen, lokale Konfiguration, Cache

Често в Paradox-структурата има локални таблици за междинни резултати, буфер за експорти, потребителски оформления или параметри. Някои неща трябва да останат локални (напр. UI-оформления), други да станат централни (напр. работни процеси, статуси, логове). Миграцията е възможност тези категории да се изчистят.

Stolpersteine bei Paradox/BDE: typische technische Unterschiede

За да стане миграцията планирана, полезно е да се адресират повтарящите се разлики ясно.

SQL-Dialekt und Operatoren

BDE/Paradox-SQL не е идентичен с MySQL/MariaDB-SQL. Различията се проявяват при функции за дати, string-функции, outer joins (исторически), логика на Like/маски и при имплицитни конвертации на типове. Контролираният подход замества „работи някак“ с ясни правила: кои изрази се портват, кои се пренаписват умишлено, кои се капсулират в Views/Stored Procedures (ако е разумно)?

Sortierung und Collation

В Paradox редът на сортиране и чувствителността към регистър често се различава от MariaDB, особено при умлаутите. В MariaDB Collation-ът (напр. utf8mb4_german2_ci срещу utf8mb4_unicode_ci) определя сравнения и сортиране. Това не е академичен въпрос: влияе на дедупликация, функции за търсене и поведението на уникални ограничения.

Autoincrement und Nummernkreise

Paradox има autoincrement-поля, но приложенията често използват собствените си номерни серии (номери на документи, поръчки) със специална логика. В MariaDB трябва ясно да се отдели:

• Technischer Primärschlüssel: AUTO_INCREMENT (или UUID, в зависимост от архитектурата) за връзките.
• Fachliche Nummer: собствен номерен кръг с транзакционна защита, евентуално на ниво клиен/период.

Който опита да злоупотреби с fachliche-номер като технически ключ, ще си навлече скъпи промени по-късно.

Locking und Transaktionen

Преминаването от файлов достъп към истински сървър е придобивка, но променя поведението. В MariaDB транзакциите (InnoDB) са централни. Трябва да се реши къде са границите на транзакциите: за диалог, за операция за запис, за batch. Особено важно: дълги транзакции и „режим на редакция“ в продължение на минути са чести в Paradox-средите, но на сървъра са критични (locks, deadlocks, репликационно забавяне). Адаптация на работния процес или на UI често е част от миграцията.

Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang

В B2B среди стабилността на операцията е често по-важна от бързото превключване. Поетапен миграционен път намалява риска, тъй като предметната област и IT могат итеративно да валидират.

Etappe 1: Datenmodell-Transfer mit Mapping, ohne Code-Umbau

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

Deliverables в тази фаза обикновено са:

• Definieren на схема (DDL) под версия контрол (напр. в Git)
• Списък за поле-мепинг (Paradox → MariaDB) включително правила за конверсия
• Процедура за импорт с логиране (брой записи, грешки, изключения)
• Първични валидационни репорти (Counts, суми, checksums)

Etappe 2: BDE-Ablösung im Datenzugriff (z. B. mit FireDAC)

Реалната стъпка за модернизация е отвързване от BDE. В Delphi проекти BDE-Ablosung mit nativer Anbindung е доказан подход, защото предлага модерни драйвери, транзакции, параметрични заявки и унифицирани компоненти за различни SQL-backend-и. Решаващо не е просто „да махнем BDE“, а как ще изглежда кодът след това: централен достъп до данни, ясна обработка на грешки, чисти параметри вместо конкатенация на низове.

Типични задачи в тази фаза:

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

Ако приложението ви трябва да се модернизира в дългосрочен план, тази стъпка често е по-важна от самата миграция на данни. Тя дава техническата свобода за 64‑Bit, модерни Windows-версии и чисти deployment-пайплайни.

Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch

За критични системи е разумно да се поддържа паралелен режим: MariaDB се изгражда и циклично (или инкрементално) се напълва, докато старото решение продължава да работи. Така предметната област може да сравнява справки, да идентифицира гранични случаи и да тества новата платформа под натоварване. Паралелният режим може да се реализира по различни начини:

• Read-only-реплика за подготовка на отчетност/BI
• „Dual Write“ в дефинирани подсфери (само ако е добре управлявано)
• Миграция на зададен момент със многократни сухи проби и ясна Cutover-чеклист

Важно е да не се усложнява излишно: Dual-Write звучи привлекателно, но е рисково, ако предметната логика не е централна. Често повторяемият стichtagslauf с добра валидация е по-икономичен накрая.

Etappe 4: Optimierung, Integrität, Performance, Betriebsprozesse

След Cutover започва фазата, в която MariaDB трябва да покаже силите си: референтна цялост, ефективни индекси, чисти права, мониторинг, тестове за backup/restore. Тук обикновено се проявяват „реалните“ продукционни натоварвания: дълги отчети, лошо индексирани търсения, batch-ъпдейти. Контролираната миграция предвижда тази фаза изрично, а не я оставя като непланирана доработка.

Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust

Мапингът на полетата е сърцето на миграцията. Типични съпоставяния (опростено) са:

• 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? Кои default-стойности са предметно коректни? Кои комбинации трябва да са уникални? От това произтичат constraints и индекси. Тези правила в Paradox/BDE системите често са били имплицитни в UI или код — в MariaDB те, където е разумно, следва да станат явни.

Integrität: Primary Keys, Foreign Keys und eindeutige Indizes nachziehen

Много legacy-бази работят години без референтна цялост — докато интеграции, портали или паралелни процеси не се появят. Тогава качеството на данните става лимитиращ фактор. В MariaDB могат да се вкарат foreign keys, unique constraints и checks (в зависимост от версията/engine), за да се предотвратяват грешки в ранна фаза.

Практичен подход е въвеждането на цялост поетапно:

• Първо Primary Keys и уникални индекси върху ключови обекти (клиенти, артикули, документи)
• После Foreign Keys в стабилните области
• За „исторически“ таблици с данни-мусор: първо почистване, после constraints

Това намалява риска Cutover да се провали заради стари проблеми и все пак подобрява цялостното състояние значително.

Performance in der Praxis: was sich mit MariaDB ändert

Paradox/BDE системите често са оптимизирани за „скорост на файл“: локални индекси, бърз достъп до таблици, много клиентско филтриране. При MariaDB работата се премества към сървъра. Това е положително, но изисква чисти SQL- и индекс-стратегии.

Typische Performance-Fallen

• SELECT * от големи таблици, защото преди „локално“ е било достатъчно бързо
• Clientseitiges Filtern вместо serverseitige WHERE-клауза
• Fehlende zusammengesetzte Indizes върху полета за търсене (напр. мандант + статус + дата)
• LIKE ‚%text%‘ без подходяща fulltext-стратегия

Messbar verbessern statt „nach Gefühl“

Контролираната миграция въвежда отначало измервателни точки: slow query log, Explain-анализи, възпроизводими натоварвания. Това е особено важно, когато след миграцията се планират допълнителни компоненти като REST-Server или Kundenportal, които променят модела на достъп (много малки заявки, paging, search endpoints).

Delphi-spezifisch: BDE-Ablösung, FireDAC und saubere Zugriffsschichten

В Delphi проекти техническата модернизация е тясно свързана с достъпа до данни. BDE не е просто „драйвер“, а цял стил на достъп (TTable, записно-ориентиран, навигиране, локални филтри). Миграцията към MariaDB е правилният момент за консолидиране на достъпа.

Von „DataSets überall“ zu kontrolliertem Datenzugriff

Много приложения имат вградено в всяка форма собствено запитване. Това мащабира лошо от предметна и сигурностна гледна точка. Работещ подход е преминаване към:

• Централни repository-/service-класове за ключови обекти
• Унифицирано обработване на грешки и транзакции
• Параметризирани заявки (за да се предотврати SQL Injection, да се използва кеширане на планове)
• Конфигурируеми connection-пули или управление на връзките за услуги

Това създава основа за Layer-3 архитектура, в която UI, предметна логика и персистентност са ясно отделени. Ползата е не само при смяната на базата, но и при по-нататъшното развитие към REST-Server или фонодни услуги.

MariaDB-Anbindung mit FireDAC: was typischerweise zu klären ist

В проектите винаги изплуват едни и същи въпроси: коя драйвер версия (MySQL/MariaDB), кои SSL-опции, кои timezone и дата-опции, кои Unicode-настройки? Това не са дреболии, защото влияят директно на консистентността на данните (дата/час), сортирането и сигурността на работата (TLS). Контролираната миграция фиксира тези параметри, документира ги и ги тества с реалистични данни.

Cutover-Plan: Stichtag, Datenfreeze, Rollback – ohne Überraschungen

Cutover-ът е отделен проект. Добрият план за превключване описва не само „кога ще се превключи“, но и защитните мерки:

• Datenfreeze: От кога в стария систем не се въвеждат нови данни? Има ли аварийни процеси?
• Finaler Import: Колко реалистично ще продължи? (сухите пускания дават числа.)
• Validierung: Кои проверки трябва да са зелени преди пуск (counts, суми, извадки, предметни отчети)?
• Rollback: Кога се прекратява и какво следва тогава?
• Kommunikation: Кой дава одобрение? Кой е на разположение в War Room?

Особено в средния бизнес „rollback“ често е не толкова технически, колкото организационно критичен. Затова миграцията трябва да бъде подготвена така, че Cutover-ът да не е експеримент, а пробван процес.

Nach der Migration: Basis für REST, Services und Multiplattform

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

Важно: REST-Server не е „още един слой“, а архитектурно решение. Който вече е консолидирал достъпа до данни, валидациите и правата в services/repositories, може значително по-лесно да разработи стабилни APIs.

Praxis-Checkliste: Was Sie vor Projektstart klären sollten

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

Тези уточнения не са бюрокрация, а предотвратяват ситуацията, при която миграцията е „технически готова“, но не е приета предметно.

Fazit: Kontrolliert migrieren heißt Risiken planbar machen

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

Поетапен подход с възпроизводим импорт, чисто поле-мепинг, ранна валидация и ясна BDE-отмяна (напр. чрез FireDAC) изгражда стабилна основа: за многопотребителска работа, за интеграции, за услуги и за следващите стъпки на Delphi Modernisierung.

Ако искате да планирате миграцията си предметно и да я реализирате без оперативни прекъсвания, ще обсъдим с удоволствие стартовата ситуация, рисковете и реалистичен поетапен план: https://net-base-software-gmbh.de/kontakt/