Paradox a BDE kontrolovane migrovať na MariaDB

Mnohé Delphi-odvetvové aplikácie vznikli s Paradox tabuľkami a Borland Database Engine (BDE), pretože to bol vtedy pragmatický štandard: lokálne, rýchlo pripravené, s minimálnou infraštruktúrou. V praxi tieto systémy často bežia produktívne až dodnes – vrátane reportingu, tlače etikiet, importu/exportu, batch jobov, historických tabuliek a špeciálnej logiky, ktorá sa počas rokov „vryla“ do prístupu k dátam. Práve preto nie je migrácia len exportom dát, ale kontrolovanou prestavbou: dátový model, správanie SQL, vedľajšie efekty v kóde a prevádzkové procesy musia byť posudzované spoločne.

MariaDB je ako cieľová platforma často veľmi dobrá voľba, ak ide o robustný viacužívateľský prevádzkový režim, konzistentné transakcie, centrálne zálohy, replikáciu, jasnú správu práv a pripojiteľnosť pre webportály, služby alebo REST-API. Výzvou pritom zriedka býva inštalácia databázy – skutočný objem práce leží v bezpečnej migračnej trase: ako sa tabuľky, indexy, primárne kľúče, znakovité sady, dátumové polia, „prázdne“ hodnoty a referenčné vzťahy správne prenesú, bez toho aby sa porušila fachová logika počas bežiacej prevádzky?

Tento príspevok popisuje osvedčený postup, ako kontrolovane migrovať Paradox a BDE na MariaDB: technicky podložené, etapové a so zameraním na stabilitu. Cieľom je udržateľný základ pre ďalšie kroky modernizácie – napríklad BDE-odstránenie, prechod na BDE-Ablösung mit nativer Anbindung, jasná Layer-3 architektúra, REST-servery a multiplatformní klienti.

Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel

Paradox ako formát súborov a BDE ako prístupová vrstva tvoria celkový systém so špecifikami, ktoré by sa v MariaDB nemali 1:1 „napodobňovať“. Typické príznaky v každodennej prevádzke sú:

• Nepriehľadné závislosti: SQL príkazy sú roztrúsené (formuláre, DataModules, reporty, dynamické string-SQL), často bez centrálnej správy.
• Správanie „podľa pocitu“: Niektoré filtre, triedenia alebo joiny fungujú náhodne, pretože Paradox/BDE je tolerantný alebo implicitne konvertuje typy.
• Limity viacužívateľského režimu: Zámky na úrovni súborov, pokles výkonu v sieti, problémy s lockingom pri rastúcom objeme dát.
• Riziká údržby: Závislosti na BDE, staré ovládače, náročné nasadzovanie na moderných Windows-verziách, 64‑Bit/ARM64 témy.

Kontrolovaná migrácia tieto body neberie len ako vedľajší efekt, ale definuje ich ako kritériá úspechu. MariaDB pritom nie je len „nová databáza“, ale šanca oddeliť dátovú prístupovú vrstvu, zvýšiť fachovú integritu a vytvoriť pripojiteľné rozhrania.

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

Zmysluplný cieľový obraz pre B2B odvetvové aplikácie zvyčajne pozostáva z troch vrstiev:

• Databáza (MariaDB): konzistentné ukladanie dát, indexy, constraints, transakcie, používatelia/role, zálohy.
• Fachlogik (Server/Services): validácie, workflowy, importéry, schedulery, rozhrania. Voliteľne ako REST-Server, Windows- alebo Linux-Services.
• Klienti (VCL/FMX/Web): používateľské rozhrania, reporty, offline časti, integrácie. Ideálne s jasnými kontraktmi k fachovej logike.

Podľa východiskovej situácie nie je potrebné všetko realizovať naraz. Migrácia by však mala byť naplánovaná tak, aby neblokovala cestu k čistej architektúre. Kto dnes len skopíruje tabuľky a zajtra opäť „priamo“ z každého formulára zapisuje do databázy, síce zavedie MariaDB, ale skutočné riziká pretrvajú.

Bestandsaufnahme: Was wirklich migriert werden muss

Na začiatku stojí inventúra, ktorá presahuje otázku „koľko tabuliek“. V Paradox/BDE projektoch je bežné, že databáza predstavuje len časť pravdy. Dôležité body:

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

Často chýbajú skutočné primárne kľúče. Namiesto toho existujú kombinácie polí, poradové čísla bez jednoznačného constraintu alebo „key“ polia, ktoré sa udržiavajú v aplikácii. Pre MariaDB z toho musia vzniknúť jednoznačné, robustné kľúče – inak sú transakcie a referenčná integrita len čiastočne účinné.

2) Queries, dynamische SQL-Bausteine, Reports

BDE používa podľa komponentu rôzne SQL dialekty a toleruje „kreatívne“ statementy. Reportingové komponenty (aj staršie) často obsahujú vlastné SQL definície. Migrácia musí tieto zdroje nájsť a kategorizovať: kritické jadrové query, zriedka používané výstupy, špeciálne importy.

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

Mnohé Paradox aplikácie sú historicky ANSI‑based. Ak sa Delphi aplikácia sama niekedy prešla na Unicode, vznikajú zmiešané scenáre: dáta sú v starom encodingu, UI je Unicode, exporty očakávajú Windows‑1252. MariaDB by tu mala dostať jasný koncept (typicky utf8mb4), vrátane dôslednej konverzie a testov na „neviditeľné“ chyby (porovnávania, triedenie, Trim/Pad, špeciálne znaky).

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

Paradox/BDE pozná rôzne špeciálne prípady: prázdne reťazce namiesto NULL, 0‑dátumy, „prázdne“ timestampty, defaulty vznikajúce v UI. MariaDB striktne rozlišuje medzi NULL a prázdnym reťazcom. To ovplyvňuje WHERE klauzuly, agregácie a výpočty. Tieto rozdiely treba prehodnotiť pre každú tabuľku/pole.

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

V Paradox štruktúre sa často nachádzajú lokálne tabuľky pre medzivýsledky, exportné buffery, používateľské rozloženia alebo parametre. Niektoré údaje patria naďalej lokálne (napr. UI rozloženia), iné by mali byť centralizované (napr. pracovné úlohy, statusy, logy). Migrácia je príležitosť tieto kategórie jasne oddeliť.

Stolpersteine bei Paradox/BDE: typische technische Unterschiede

Aby bola migrácia plánovateľná, oplatí sa opakovane sa vyskytujúce rozdiely explicitne adresovať.

SQL-Dialekt und Operatoren

BDE/Paradox‑SQL nie je identické s MySQL/MariaDB‑SQL. Rozdiely sa prejavujú napr. pri dátumových funkciách, reťazcových funkciách, outer joineoch (históricky), LIKE/maskovej logike a pri implicitných konverziách typov. Kontrolovaný prístup nahradí „funguje aj tak“ jasnými pravidlami: ktoré statementy sa portujú, ktoré sa vedome prepíšu, ktoré sa zabalia do view/uložených procedúr (ak dáva zmysel).

Sortierung und Collation

V Paradox sú poradia triedenia a rozlišovanie veľkých/malých písmen často odlišné než v MariaDB, najmä pri umlautocht. V MariaDB určuje collation (napr. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) porovnávanie a triedenie. Nie je to akademická otázka: ovplyvní to deduplikáciu, vyhľadávanie a správanie unique constraintov.

Autoincrement und Nummernkreise

Paradox má autoincrement polia, avšak aplikácie často používajú vlastné číselné rady (čísla dokladov, objednávok) so špeciálnou logikou. V MariaDB by sa malo dôsledne oddeliť:

• Technický primárny kľúč: AUTO_INCREMENT (alebo UUID, podľa architektúry) pre vzťahy.
• Fachové číslo: vlastný číselný rad so transakčnou ochranou, prípadne per klient/obdobie.

Kto zneužije fachové číslo ako technický kľúč, vystaví sa neskorším nákladným prestavbám.

Locking und Transaktionen

Prechod z prístupov založených na súboroch na skutočný server prináša zisk, ale mení správanie. V MariaDB sú transakcie (InnoDB) centrálnym prvkom. Treba rozhodnúť, kde sú hranice transakcií: na dialóg, pri uložení, pri batche. Zvlášť dôležité: dlhé transakcie a „editovací mód“ trvajúci minúty sú v Paradox prostredí bežné, no na serveri sú rizikové (zamykánie, deadlocky, replikačné zaostávanie). Úprava pracovných postupov alebo UI je preto často súčasťou migrácie.

Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang

V B2B prostredí je prevádzková stabilita často dôležitejšia ako rýchly rez. Etapová migračná cesta znižuje riziko, pretože fachové oddelenie a IT môžu iteratívne validovať.

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

V prvom kroku sa vytvorí MariaDB schéma, ktorá zobrazuje Paradox štruktúru – avšak už s cieľovými princípmi: primárne kľúče, indexy, vhodné dátové typy, utf8mb4, InnoDB. Paralelne sa vytvorí reprodukovateľný importný proces (skripty/nástroje), ktorý je možné pri potrebe opakovane spustiť. Dôležitá je opakovateľnosť, pretože migrácia nikdy nie je „hotová“ po prvom behu.

Výstupy tejto etapy sú typicky:

• Verzionovaná definícia schémy (DDL) (napr. v Gite)
• Zoznam mapovania polí (Paradox → MariaDB) vrátane pravidiel konverzie
• Importná procedúra s protokolovaním (počet záznamov, chyby, odchýlky)
• Prvé validačné reporty (počty, sumy, kontrolné sumy)

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

Skutočný modernizačný krok je odpojenie od BDE. V Delphi projektoch je BDE-Ablosung mit nativer Anbindung osvedčená cesta, pretože prináša moderné ovládače, transakcie, viazanie parametrov a jednotné komponenty pre rôzne SQL backendy. Rozhodujúce nie je „BDE von“, ale ako potom vyzerá kód: centralizovaný dátový prístup, jasné ošetrenie chýb, čisté parametre namiesto zreťazovania stringov.

Typické úlohy v tejto etape:

• Nahradenie TTable/TQuery pomocou FireDAC‑Query a DataSetov
• Zavedenie data‑access vrstvy (DAL) ako základ pre neskoršiu Layer-3 architektúru
• Štandardizácia transakčných rozsahov (Commit/Rollback)
• SQL‑review: prispôsobenie dialektu, parametre, paging, joiny

Ak má vaša aplikácia dlhodobo podstúpiť modernizáciu, je tento krok často dôležitejší než samotná migrácia dát. Vytvára technickú slobodu pre 64‑Bit, moderné Windows‑verzie a čisté deployment pipeline.

Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch

Pre kritické systémy má zmysel prevádzka v paraleli: MariaDB sa postaví a cyklicky (alebo inkrementálne) napĺňa, kým starý systém pokračuje. Fachové oddelenie tak môže porovnávať výstupy, identifikovať hraničné prípady a testovať novú platformu pod záťažou. Parallelbetrieb možno zrealizovať rôzne:

• Read‑only replika pre reporting/BI prípravu
• „Dual Write“ v definovaných oblastiach (len ak je to dobre zvládnuté)
• Stichtagsmigration s viacerými suchými behmi a jasným cutover checklistom

Dôležité je nepreceňovať komplexitu: Dual‑Write znie lákavo, ale je to chybové miesto, ak fachová logika nie je centralizovaná. Často je opakovateľný stichtagslauf s dôkladnou validáciou na konci ekonomickejší.

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

Po cutover začína fáza, v ktorej má MariaDB ukázať svoje silné stránky: referenčná integrita, výkonné indexy, čisté práva, monitoring, testy backup/restore. Až tu sa často prejavia „skutočné“ produkčné zaťaženia: dlhé reporty, zle indexované vyhľadávacie masky, batch‑updaty. Kontrolovaná migrácia túto etapu explicitne plánuje, namiesto toho, aby vznikla ako neplánovaná dohoda neskôr.

Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust

Mapovanie polí je jadrom migrácie. Typické priradenia (zjednodušene) sú:

• Alpha / Memo: VARCHAR/TEXT (s utf8mb4), kontrola dĺžok a pravidlá trimovania
• Number: INT/BIGINT/DECIMAL podľa rozsahu hodnôt; opatrne pri implicitných desatinných miestach
• Date/Time: DATE/DATETIME/TIMESTAMP; jasné pravidlá pre „0‑datum“ resp. NULL
• Logical: BOOLEAN resp. TINYINT(1) s jednoznačnou sémantikou
• Currency: DECIMAL(… ,2/4) namiesto float, aby sa predišlo chybám zaokrúhľovania

Dôležité je nielen preložiť dátové typy, ale aj zdokumentovať fachové pravidlá: Môže byť pole NULL? Aké defaulty sú fachovo správne? Ktoré kombinácie musia byť jednoznačné? Z týchto pravidiel vyplývajú constraints a indexy. Tieto pravidlá boli v Paradox/BDE systéme často implicitné v UI alebo v kóde – v MariaDB by mali byť tam, kde to má zmysel, explicitné.

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

Mnohé legacy databázy fungujú roky bez referenčnej integrity – až kým neprídu integrácie, portály alebo paralelné procesy. Vtedy sa kvalita dát stáva limitujúcim faktorom. V MariaDB je možné využiť Foreign Keys, Unique Constraints a Checks (podľa verzie/enginu), aby sa chyby v dátach odchytávali včas.

Praktická cesta je zavádzať integritu postupne:

• Najprv primárne kľúče a jednoznačné indexy na kľúčových objektoch (zákazníci, artikle, doklady)
• Potom Foreign Keys v stabilných oblastiach
• Pre „historické“ tabuľky s dátovým neporiadkom: najprv čistenie, potom constraints

Tým sa znižuje riziko, že cutover zlyhá kvôli starým záťažiam, a súčasne sa výrazne zlepšuje celková situácia.

Performance in der Praxis: was sich mit MariaDB ändert

Paradox/BDE systémy sú často optimalizované na „rýchlosť súborov“: lokálne indexy, rýchle čítanie tabuliek, veľa klientského filtrovania. Pri MariaDB sa práca presúva na server. To je výhoda, ale vyžaduje čistú SQL a indexovú stratégiu.

Typische Performance-Fallen

• SELECT * z veľkých tabuliek, pretože kedysi „lokálne“ to bolo dosť rýchle
• Klientské filtrovanie namiesto serverových WHERE klauzúl
• Chýbajúce zložené indexy pre vyhľadávacie masky (napr. mandant + status + dátum)
• LIKE ‚%text%‘ bez vhodnej fulltext stratégie

Messbar verbessern statt „nach Gefühl“

Kontrolovaná migrácia zavádza skoro meracie body: Slow Query Log, Explain analýzy, reprodukovateľné záťažové testy. To je obzvlášť dôležité, ak po migrácii plánujete ďalšie komponenty, napr. REST‑server alebo Kundenportal, ktoré vytvoria nové vzory prístupu (veľa malých požiadaviek, paging, vyhľadávacie endpointy).

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

V Delphi projektoch je technická modernizácia úzko spätá s dátovým prístupom. BDE nie je len „ovládač“, ale kompletný štýl prístupu (TTable, prístup po recordoch, navigácia, lokálne filtre). Migrácia na MariaDB je správny moment konsolidovať prístup.

Von „DataSets überall“ zu kontrolliertem Datenzugriff

Mnohé aplikácie majú v každom formulári vlastné query. To sa z hľadiska fachovosti a bezpečnosti zle škáluje. Overený prístup smeruje k:

• Centralizovaným repository/service triedam pre kľúčové objekty
• Jednotnému ošetrovaniu chýb a transakcií
• Parametrizovaným query (zabrániť SQL injection, využiť plan‑caching)
• Konfigurovateľnému connection‑poolingu alebo správe spojení pre služby

Tým vzniká základ pre Layer-3 architektúru, kde UI, fachovka a perzistencia sú jasne oddelené. To pomôže nielen pri zmene DB, ale aj pri neskoršom rozšírení smerom k REST‑serverom alebo background službám.

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

V projektoch sa opakovane objavujú tie isté otázky: ktorá varianta ovládača (MySQL/MariaDB), aké SSL možnosti, ktoré timezone a dátumové nastavenia, aké Unicode nastavenia? Nie sú to detaily, lebo priamo ovplyvňujú konzistenciu dát (dátum/čas), triedenie a prevádzkovú bezpečnosť (TLS). Kontrolovaná migrácia tieto parametre stanoví, zdokumentuje a otestuje s realistickými dátami.

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

Cutover je samostatný projekt. Dobrý cutover plán popisuje nielen „kedy prepnúť“, ale aj ochranné opatrenia:

• Datenfreeze: Od kedy sa v starom systéme už nezapisuje? Existujú núdzové postupy?
• Finaler Import: Ako dlho to realisticky trvá? (Suché behy dajú čísla.)
• Validierung: Ktoré kontroly musia byť pred uvoľnením zelené (počty, sumy, vzorky, fachové reporty)?
• Rollback: Kedy sa odstúpi a ako sa postupuje ďalej?
• Kommunikation: Kto dá povolenie? Kto je v war roome dostupný?

Práve v stredne veľkých firmách nie je rollback často technický, ale organizačne kritický. Preto musí byť migrácia pripravená tak, aby cutover nebol experiment, ale nacvičený postup.

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

Keď MariaDB beží stabilne a BDE‑odstránenie je vykonané čisto, otvárajú sa nové možnosti: REST‑API pre externé systémy, background spracovanie ako Windows‑ alebo Linux‑services, oddelenie UI od fachovej logiky a perspektívne multiplatformní klienti. Častý nasledujúci krok je vytiahnuť fachovú logiku z desktopu, aby integrácie (ERP/DMS/CRM) a portály boli obsluhované kontrolovane.

Dôležité je: REST‑Server nie je „ďalšia vrstva“, ale architektonické rozhodnutie. Kto už má prístup k dátam, validácie a autorizáciu skonsolidované v službách/repository, dokáže z toho relatívne ľahko vytvoriť robustné API.

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

• Ktoré moduly sú kľúčové pre biznis a musia na deň cutover fungovať bez výpadku?
• Aké sú reálne objemy dát (veľkosti tabuliek, rast, archivácia)?
• Ktoré reporty musia byť 1:1 identické a ktoré môžu byť vylepšené?
• Aké integrácie sú napojené na systém (exporty súborov, ODBC, Office, tlačové linky)?
• Existuje multitenantnosť a ak áno: ako je dnes zobrazená?
• Aké prevádzkové požiadavky platia (okno pre zálohy, čas na restore, práva, audit)?

Tieto otázky nie sú byrokracia, ale zabraňujú tomu, aby migrácia bola „technicky hotová“, no fachovo neprevzatá.

Fazit: Kontrolliert migrieren heißt Risiken planbar machen

Kontrolovaná migrácia Paradox a BDE na MariaDB znamená modernizovať aplikáciu ako celok: dátový model, SQL, transakcie, znakovú sadu, prístupovú vrstvu a prevádzkové procesy. Kto vníma zmenu len ako čistý export, zvyčajne získa presne tie problémy, ktorých sa chcel zbaviť – len na novom serveri.

Etapový prístup s reprodukovateľným importom, dôsledným mapovaním polí, skorou validáciou a jasným BDE‑odstránením (napr. cez FireDAC) vytvára stabilný základ: pre viacužívateľský prevádzok, pre integrácie, pre služby a pre ďalšie kroky Delphi Modernisierung.

Ak chcete svoju migráciu fachovo bezpečne naplánovať a realizovať bez prevádzkového prerušenia, radi s vami preberieme východiskovú situáciu, riziká a realistický etapový plán: https://net-base-software-gmbh.de/kontakt/