Paradox a BDE kontrolovaně migrovat na MariaDB

Mnoho Delphi odborných aplikací vzniklo s Paradox tabulkami a Borland Database Engine (BDE), protože to tehdy byl pragmatický standard: lokální, rychle připravené k provozu, s minimální infrastrukturou. V praxi tyto systémy často běží produktivně dodnes – včetně reportingu, tisku štítků, importu/exportu, dávkových úloh, historizačních tabulek a speciální logiky, která se za roky „vryla“ do přístupu k datům. Právě proto není migrace jen export dat, ale kontrolovaná přestavba: datový model, SQL-chování, vedlejší dopady v kódu a provozní procesy musí být posuzovány společně.

MariaDB je jako cílová platforma často velmi dobrou volbou, pokud jde o robustní víceuživatelský provoz, konzistentní transakce, centrální zálohy, replikaci, jasnou správu práv a napojitelnost pro webová portály, služby nebo REST-API. Výzvou nebývá instalace databáze – skutečné úsilí je v bezpečné migrační cestě: Jak převést tabulky, indexy, primární klíče, znakovou sadu, datová pole, „prázdné“ hodnoty a referenční vztahy správně, aniž by provozní doménová logika přestala fungovat?

Tento článek popisuje osvědčený postup, jak Paradox a BDE kontrolovaně migrovat do MariaDB: technicky podloženě, etapově a s důrazem na stabilitu. Cílem je udržitelná základna pro další kroky modernizace – například BDE-výstřih, přechod na BDE-Ablösung mit nativer Anbindung, jasná Layer-3 Architektur, REST-Server a multiplatformní klienti.

Proč je migrace Paradox/BDE víc než výměna databáze

Paradox jako formát souboru a BDE jako přístupová vrstva tvoří celek s vlastnostmi, které se v MariaDB nevyplatí 1:1 „překopírovat“. Typické symptomy v každodenním provozu jsou:

• Net transparentní závislosti: SQL příkazy jsou rozprostřeny (Formy, DataModules, Reporty, dynamické string‑SQL), často bez centrální governance.
• Chování „na pocit“: Některé filtry, řazení nebo joiny fungují náhodou, protože Paradox/BDE je tolerantní nebo implicitně převádí typy.
• Limity víceuživatelského provozu: Zámky na souborech, propady výkonu v síti, problémy s lockingem při rostoucím objemu dat.
• Rizika údržby: Závislosti na BDE, staré ovladače, komplikované nasazení na moderních Windows verzích, 64‑Bit/ARM64 témata.

Kontrolovaná migrace tyto body nebere jako vedlejší efekt, ale jako hodnotící kritéria. MariaDB se tak nestává jen „novou databází“, ale příležitostí k odpojení přístupu k datům, zvýšení doménové integrity a zajištění rozhraní pro další systémy.

Cílový obraz: MariaDB jako stabilní datová základna pro desktop, služby a portály

Smysluplný cílový obraz pro B2B odborné aplikace má obvykle tři vrstvy:

• Databáze (MariaDB): konzistentní uchování dat, indexy, omezení, transakce, uživatelé/role, zálohy.
• Doménová logika (Server/Services): validace, workflowy, importéry, plánovače, rozhraní. Volitelně jako REST-Server, Windows‑ nebo Linux-Services.
• Klienti (VCL/FMX/Web): uživatelská rozhraní, reporty, offline části, integrace. Ideálně s jasnými kontrakty vůči doménové logice.

Podle výchozí situace není nutné všechno zavést najednou. Migrace by ale měla být plánována tak, aby neblokovala cestu k čisté architektuře. Kdo dnes jen okopíruje tabulky a zítra opět „přímo“ z každého formuláře píše do databáze, ten sice zavedl MariaDB, ale skutečná rizika zůstávají.

Inventura: Co se skutečně musí migrovat

Na začátku stojí inventura, která jde dál než jen „kolik tabulek“. V Paradox/BDE projektech je běžné, že databáze je jen část pravdy. Důležité body:

1) Tabulky, indexy, „pseudo‑klíče“

Často chybějí skutečné primární klíče. Místo toho existují kombinace polí, pořadová čísla bez jednoznačného omezení nebo „key“ pole, která jsou udržována v aplikaci. Pro MariaDB z toho musí vzniknout jednoznačné, odolné klíče – jinak jsou transakce a referenční integrita jen omezeně účinné.

2) Dotazy, dynamické SQL‑části, reporty

BDE používá v závislosti na komponentě různé SQL dialekty a toleruje „kreativní“ příkazy. Reportingové komponenty (i starší) často obsahují vlastní SQL definice. Migrace musí tyto zdroje najít a kategorizovat: kritické jádrové dotazy, zřídka používané výstupy, speciální importy.

3) Znaková sada a speciální znaky (umlauty, ISO/ANSI, Unicode)

Mnoho Paradox aplikací má historicky ANSI základ. Pokud byla Delphi aplikace sama někdy převedena na Unicode, vznikají smíšené světy: data v starém kódování, UI v Unicode, exporty očekávají Windows‑1252. MariaDB by zde měla dostat jasný koncept (typicky utf8mb4), včetně čisté konverze a testů na „neviditelné“ chyby (porovnání, řazení, trim/pad, speciální znaky).

4) „Prázdné“ hodnoty, logika NULL a datová pole

Paradox/BDE zná různé speciální případy: prázdné řetězce místo NULL, 0‑data, „prázdné“ timestampy, defaultní hodnoty vznikající v UI. MariaDB striktně rozlišuje mezi NULL a prázdným řetězcem. To ovlivňuje WHERE klauzule, agregace a výpočty. Tyto rozdíly je třeba pro každou tabulku/pole vyhodnotit.

5) Vedlejší artefakty: session‑tabulky, lokální konfigurace, cache

V Paradox struktuře často leží lokální tabulky pro mezivýsledky, vyrovnávací paměť exportů, uživatelská rozložení nebo parametry. Některé věci patří i nadále lokálně (např. UI‑rozložení), jiné by měly být centrální (např. pracovní postupy, stavy, logy). Migrace je příležitostí tyto kategorie jasně oddělit.

Úskalí u Paradox/BDE: typické technické rozdíly

Aby byla migrace plánovatelná, vyplatí se opakující se rozdíly explicitně adresovat.

SQL dialekt a operátory

BDE/Paradox‑SQL není totožný s MySQL/MariaDB‑SQL. Rozdíly se objevují např. u funkcí pro datum, stringových funkcí, outer joinů (historicky), logiky Like/masky a implicitních konverzí typů. Kontrolovaný přístup nahradí „funguje to“ jasnými pravidly: které příkazy se přenesou, které se záměrně přepíšou, které se zabalí do view/procedur (pokud má smysl).

Řazení a collation

V Paradox jsou pořadí řazení a rozlišování velkých/malých písmen často jiné než v MariaDB, zejména u umlautů. V MariaDB rozhoduje collation (např. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) o porovnání a řazení. Není to akademická otázka: ovlivňuje deduplikaci, vyhledávání a chování unique constraintů.

Autoincrement a číselné řady

Paradox má pole s autoincrementem, ale aplikace často používají vlastní číselné řady (čísla dokladů, objednávek) se speciální logikou. V MariaDB by mělo být jasně odděleno:

• Technický primární klíč: AUTO_INCREMENT (nebo UUID, podle architektury) pro vazby.
• Funkční číslo: vlastní číselná řada s transakční ochranou, případně per mandant/období.

Kdo zneužije funkční číslo jako technický klíč, připraví si později nákladné úpravy.

Locking a transakce

Přesun z přístupu založeného na souborech na skutečný server je přínos, ale mění chování. V MariaDB jsou středem transakce (InnoDB). Je třeba rozhodnout, kde leží transakční hranice: na úrovni dialogu, operace uložení nebo dávky. Zvlášť citlivé jsou dlouhé transakce a „režim úprav“ trvající minuty – v Paradox světech běžné, na serverové straně kritické (locky, deadlocky, replikace). Úprava pracovních postupů nebo UI je proto často součástí migrace.

Postup: kontrolovaná migrace v etapách místo Big Bang

V B2B prostředí je provozní stabilita často důležitější než rychlý řez. Postupný migrační plán snižuje riziko, protože byznysová část i IT mohou iterativně ověřovat výsledky.

Etapa 1: Přenos datového modelu s mapováním, bez přepisování kódu

V prvním kroku se vybuduje MariaDB schéma, které odráží Paradox strukturu – ale už podle cílových principů: primární klíče, indexy, smysluplné datové typy, utf8mb4, InnoDB. Paralelně vznikne reprodukovatelný importní proces (skripty/nástroje), který je možno v případě potřeby opakovat. Důležitá je opakovatelnost, protože migrace nebývá hotová na první pokus.

Výstupy této etapy jsou typicky:

• Verzionovaná definice schématu (DDL), např. v Git
• Seznam mapování polí (Paradox → MariaDB) včetně konverzních pravidel
• Importní procedura s logováním (počet záznamů, chyby, odchylky)
• První validační reporty (počty, součty, kontrolní součty)

Etapa 2: BDE‑odstranění v přístupu k datům (např. s FireDAC)

Skutečný krok modernizace je oddělení od BDE. V Delphi projektech je BDE-Ablosung mit nativer Anbindung osvědčená cesta, protože nabízí moderní ovladače, transakce, vázání parametrů a jednotné komponenty pro různé SQL backendy. Rozhodující není jen „BDE pryč“, ale jak bude kód po změně vypadat: centralizovaný přístup k datům, jasné ošetření chyb, čisté parametry místo spojování stringů.

Typické úkoly v této etapě:

• Nahrazení TTable/TQuery pomocí FireDAC‑dotazů a DataSetů
• Zavedení vrstvy přístupu k datům (DAL) jako základu pro budoucí Layer-3 architekturu
• Standardizace transakčních rozsahů (Commit/Rollback)
• SQL‑revize: přizpůsobení dialektu, parametry, stránkování, joiny

Pokud má být aplikace dlouhodobě modernizována, je tento krok často důležitější než čistá migrace dat. Vytváří technickou svobodu pro 64‑bit, moderní Windows verze a čisté deployment pipeline.

Etapa 3: Paralelní provoz a odborné přejímky bez výpadku

U kritických systémů dává smysl paralelní provoz: MariaDB se zřídí a cyklicky (nebo inkrementálně) naplňuje, zatímco starý systém běží dál. Tím může byznys porovnávat výstupy, identifikovat okrajové případy a testovat novou platformu pod zátěží. Paralelní provoz lze realizovat různě:

• Read‑only replika pro reporting/BI přípravu
• „Dual Write“ v definovaných oblastech (pouze pokud je dobře kontrolováno)
• Migrační běh ke konkrétnímu datu s několika suchými běhy a jasným cutover checklistem

Důležité je nezvyšovat složitost nad nutnou míru: Dual‑Write vypadá lákavě, ale je chybové pramenem, pokud není doménová logika centralizována. Často je opakovatelný run ke stichtagu s dobrou validací na konci ekonomičtější.

Etapa 4: Optimalizace, integrita, výkon, provozní procesy

Po cutoveru nastupuje fáze, kdy MariaDB má ukázat své silné stránky: referenční integrita, výkonné indexy, jasná práva, monitoring, testy backup/restore. Teprve zde se často projeví „skutečné“ produkční zatížení: dlouhé reporty, špatně indexované vyhledávací masky, dávkové aktualizace. Kontrolovaná migrace tuto etapu plánuje explicitně, místo aby vznikla jako neplánovaná dodatečná práce.

Datové typy a mapování: z Paradox do MariaDB bez ztráty informací

Mapování polí je jádrem migrace. Typická přiřazení (zjednodušeně) jsou:

• Alpha / Memo: VARCHAR/TEXT (s utf8mb4), kontrola délek a pravidla trim
• Number: INT/BIGINT/DECIMAL podle rozsahu hodnot; pozor na implicitní desetinná místa
• Date/Time: DATE/DATETIME/TIMESTAMP; jasná pravidla pro „0‑datum“ nebo NULL
• Logical: BOOLEAN resp. TINYINT(1) s jednoznačnou sémantikou
• Currency: DECIMAL(…,2/4) místo Float, aby se zabránilo chybám zaokrouhlování

Důležité je nepřekládat jen datové typy, ale také zaznamenat doménová pravidla: Může být pole NULL? Jaké defaultní hodnoty jsou doménově korektní? Které kombinace musí být jedinečné? Z těchto pravidel vyplynou omezení a indexy. Tato pravidla bývala v Paradox/BDE systémech často implikovaná v UI nebo v kódu – v MariaDB by měla být tam, kde to dává smysl, explicitní.

Integrita: nasazení Primary Keys, Foreign Keys a unikátních indexů

Mnoho legacy databází funguje léta bez referenční integrity – dokud nepřijdou integrace, portály nebo paralelní procesy. Tehdy se kvalita dat stane limitujícím faktorem. V MariaDB lze zavést Foreign Keys, Unique Constraints a Checky (podle verze/engine), aby se chyby v datech zabránily co nejdříve.

Praktická cesta je zavádět integritu postupně:

• Nejprve Primary Keys a unikátní indexy na klíčových objektech (zákazníci, položky, doklady)
• Poté Foreign Keys v ustálených oblastech
• Pro „historické“ tabulky s datovým šumem: nejdřív očištění, pak omezení

Tím se sníží riziko, že cutover ztroskotá na starých závazcích, a přitom se výrazně zlepší celkový stav.

Výkon v praxi: co se s MariaDB změní

Paradox/BDE systémy jsou často optimalizované pro „rychlost souboru“: lokální indexy, rychlé přístupy k tabulkám, velká část filtrování na klientovi. U MariaDB se práce přesune na server. To je výhoda, ale vyžaduje čisté SQL a indexové strategie.

Typické výkonové pasti

• SELECT * z velkých tabulek, protože dříve „lokálně“ to bylo dost rychlé
• Filtrace na klientovi místo serverových WHERE klauzulí
• Chybějící složené indexy pro vyhledávací masky (např. mandant + status + datum)
• LIKE ‚%text%‘ bez vhodné fulltext strategie

Měřitelné zlepšení místo „na pocit“

Kontrolovaná migrace zavádí brzy měřicí body: Slow Query Log, Explain analýzy, reprodukovatelné zátěžové testy. To je obzvlášť důležité, pokud po migraci přijdou další komponenty, např. REST‑server nebo Kundenportal, které mění vzory přístupu (mnoho malých požadavků, stránkování, vyhledávací endpointy).

Delphi‑specificky: BDE‑odstranění, FireDAC a čisté přístupové vrstvy

V Delphi projektech je technická modernizace úzce svázaná s přístupem k datům. BDE není jen „ovladač“, ale kompletní přístupový styl (TTable, práce záznam‑po‑záznamu, navigace, lokální filtry). Migrace do MariaDB je správný okamžik konsolidovat tento přístup.

Od „DataSetů všude“ ke kontrolovanému přístupu k datům

Mnoho aplikací má v každém formuláři vlastní dotazy. To špatně škáluje z hlediska domény i bezpečnosti. Osvědčené je přejít směrem k:

• Centrálním třídám Repository/Service pro klíčové objekty
• Jednotné manipulaci s chybami a transakcemi
• Parametrizovaným dotazům (vyhnout se SQL injection, využít plan caching)
• Konfigurovatelným connection poolům nebo správě připojení pro služby

Tím vznikne základna pro Layer-3 architekturu, kde jsou UI, doménová logika a perzistence čistě odděleny. To pomůže nejen při přechodu databáze, ale i při pozdějším rozšíření směrem k REST‑serveru nebo zázemním službám.

MariaDB připojení s FireDAC: co typicky vyjasnit

V projektech se opakují stejná témata: která ovladačová varianta (MySQL/MariaDB), jaké SSL volby, nastavení časových pásem a dat, jaké Unicode nastavení? To nejsou detaily – mají přímý vliv na konzistenci dat (datum/čas), řazení a provozní bezpečnost (TLS). Kontrolovaná migrace tyto parametry stanoví, zdokumentuje a otestuje s realistickými daty.

Cutover‑plan: datum, uzamčení dat, rollback – bez překvapení

Cutover je projekt sám o sobě. Dobrý plán popisuje nejen „kdy přepnout“, ale i ochranná opatření:

• Uzamčení dat: Od kdy se v starém systému již nezaznamenávají data? Existují nouzové postupy?
• Finální import: Jak dlouho reálně trvá? (Suché běhy poskytují čísla.)
• Validace: Které kontroly musí být před uvolněním zelené (počty, součty, odběrové vzorky, klíčové reporty)?
• Rollback: Kdy se přeruší přechod a jak se postupuje dál?
• Komunikace: Kdo dává souhlas? Kdo je v „war room“ k dispozici?

Právě ve středně velkých firmách není „rollback“ často technická záležitost, ale organizačně kritická. Proto musí být migrace připravena tak, aby cutover nebyl experiment, ale nacvičený postup.

Po migraci: základ pro REST, služby a multiplatformu

Jakmile MariaDB běží stabilně a BDE‑odstranění je čistě provedeno, otevírají se nové možnosti: REST‑API pro externí systémy, pozadí jako Windows‑ nebo Linux‑služby, odpojení UI od doménové logiky a perspektiva multiplatformních klientů. Častý další krok je vytáhnout doménovou logiku z desktopu, aby se integrace (ERP/DMS/CRM) a portály obsluhovaly kontrolovaně.

Důležité je: REST‑server není „jen další vrstvička“, ale architektonické rozhodnutí. Kdo má přístup k datům, validace a práva již konsolidované v servisech/repository, ten z nich snadněji vytvoří robustní API.

Praktický checklist: Co vyjasnit před zahájením projektu

• Které moduly jsou byznysově kritické a musí v den cutoveru běžet bezchybně?
• Jaká jsou reálná datová objemová měřítka (velikost tabulek, růst, archivní koncepty)?
• Které reporty musí být 1:1 identické a které mohou být vylepšeny?
• Jaké integrace závisejí na systému (exporty souborů, ODBC, Office, tiskové trasy)?
• Existuje vícimandantnost a pokud ano: jak je dnes modelována?
• Jaké provozní požadavky platí (okno záloh, doba obnovy, práva, audit)?

Tato vyjasnění nejsou byrokracie, ale zabrání tomu, aby byla migrace „technicky hotová“, ale odborně nepřijatelná.

Závěr: Kontrolovaná migrace znamená učinit rizika plánovatelnými

Kontrolovaná migrace Paradox a BDE do MariaDB znamená modernizovat aplikaci jako celek: datový model, SQL, transakce, znakovou sadu, přístupovou vrstvu a provozní procesy. Kdo považuje přechod za pouhý export, většinou získá přesně ty problémy, kterých se chtěl zbavit – jen nyní na novém serveru.

Postupné řešení s reprodukovatelným importem, čistým mapováním polí, včasnou validací a jasným BDE‑odstraněním (např. přes FireDAC) poskytuje stabilní základnu: pro víceuživatelský provoz, pro integrace, pro služby a pro další kroky Delphi Modernisierung.

Pokud chcete svou migraci odborně naplánovat a provést bez provozních výpadků, rádi probereme výchozí stav, rizika a realistický plán etap: https://net-base-software-gmbh.de/kontakt/