Kontrolowana migracja Paradox i BDE do MariaDB

Wiele Delphi-aplikacji branżowych powstało z wykorzystaniem tabel Paradox i Borland Database Engine (BDE), ponieważ w tamtym czasie był to pragmatyczny standard: lokalny, szybko gotowy do uruchomienia, niewymagający dużej infrastruktury. W praktyce systemy te często działają produkcyjnie do dziś — łącznie z raportowaniem, drukiem etykiet, importem/eksportem, zadaniami wsadowymi, tabelami historii i specyficzną logiką, która przez lata „wrosła” w dostęp do danych. Dlatego migracja to nie tylko eksport danych, lecz kontrolowana przebudowa: model danych, zachowanie SQL, skutki uboczne w kodzie i procesy operacyjne muszą być rozpatrywane łącznie.

MariaDB jako platforma docelowa jest często bardzo dobrym wyborem, gdy chodzi o stabilny wielodostęp, poprawne transakcje, centralne kopie zapasowe, replikację, klarowne zarządzanie uprawnieniami oraz możliwość podłączenia portali webowych, usług lub REST-API. Wyzwanie rzadko stanowi instalacja bazy danych — rzeczywisty nakład pracy leży w bezpiecznej ścieżce migracji: jak poprawnie przenieść tabele, indeksy, klucze podstawowe, zestawy znaków, pola dat, „puste” wartości i relacje referencyjne, bez ryzyka naruszenia logiki fachowej podczas pracy systemu?

Ten artykuł opisuje sprawdzone podejście do kontrolowanej migracji Paradox i BDE do MariaDB: technicznie ugruntowane, etapowe i z naciskiem na stabilność. Celem jest nośna podstawa dla dalszych kroków modernizacyjnych — na przykład zastąpienie BDE, przejście na BDE-zastąpienie z natywnym dostępem, czytelna Layer-3 architektura, REST-serwery i klienci wieloplatformowi.

Dlaczego migracja Paradox/BDE to więcej niż zmiana bazy danych

Paradox jako format plików i BDE jako warstwa dostępu tworzą system całościowy z osobliwościami, których nie powinno się 1:1 „odtwarzać” w MariaDB. Typowe symptomy w codziennej eksploatacji to:

• Nieprzejrzyste zależności: instrukcje SQL są rozproszone (formularze, DataModule, raporty, dynamiczne string-SQL), często bez centralnej governance.
• Zachowanie „na wyczucie”: określone filtry, sortowania czy joiny działają przypadkowo, ponieważ Paradox/BDE jest tolerancyjny lub dokonuje implicznych konwersji typów.
• Ograniczenia wielodostępu: blokady plikowe, spadki wydajności w sieci, problemy z lockingiem przy rosnącej objętości danych.
• Ryzyka utrzymania: zależności od BDE, stare sterowniki, trudne wdrożenia na nowoczesnych wersjach Windows, zagadnienia 64‑bit/ARM64.

Kontrolowana migracja traktuje te punkty nie jako efekt uboczny, lecz jako kryteria celu. MariaDB nie jest wtedy tylko „nową bazą danych”, lecz szansą na odseparowanie warstwy dostępu do danych, podniesienie integralności merytorycznej i zapewnienie możliwości integracji.

Wizja docelowa: MariaDB jako stabilna warstwa danych dla desktopu, usług i portali

Rozsądna wizja docelowa dla aplikacji B2B składa się zwykle z trzech poziomów:

• Baza danych (MariaDB): spójne przechowywanie danych, indeksy, constraints, transakcje, użytkownicy/role, kopie zapasowe.
• Logika fachowa (Serwery/Usługi): walidacje, workflowy, importery, scheduler, interfejsy. Opcjonalnie jako REST-serwer, Windows- lub Linux-usługi.
• Klienci (VCL/FMX/Web): interfejsy obsługi, raporty, części offline, integracje. Najlepiej z jasno zdefiniowanymi kontraktami wobec logiki fachowej.

W zależności od stanu wyjściowego nie wszystko musi być wdrożone od razu. Migracja powinna być jednak planowana tak, by nie blokowała drogi do czystej architektury. Kto dziś tylko kopiuje tabele i jutro znowu „bezpośrednio” z każdego formularza pisze do bazy, wprowadził wprawdzie MariaDB, ale istotne ryzyka pozostaną.

Inwentaryzacja: co faktycznie trzeba zmigrować

Początek to inwentaryzacja, która wykracza poza „ile jest tabel”. W projektach Paradox/BDE typowe jest, że baza danych to tylko część prawdy. Ważne punkty:

1) Tabele, indeksy, „pseudo-klucze”

Często brakuje prawdziwych kluczy podstawowych. Zamiast tego istnieją kombinacje pól, numeracje bez jednoznacznych constraintów lub pola „Key”, utrzymywane po stronie aplikacji. W MariaDB muszą z nich powstać jednoznaczne, trwałe klucze — w przeciwnym razie transakcje i integralność referencyjna będą tylko częściowo skuteczne.

2) Zapytania, dynamiczne komponenty SQL, raporty

BDE w zależności od komponentu używa różnych dialektów SQL i toleruje „kreatywne” instrukcje. Komponenty raportujące (nawet starsze) często zawierają własne definicje SQL. Migracja musi te źródła odnaleźć i skategoryzować: krytyczne zapytania rdzeniowe, rzadko używane analizy, importy specjalne.

3) Zestaw znaków i znaki specjalne (umlauty, ISO/ANSI, Unicode)

Wiele aplikacji Paradox jest historycznie bazowanych na ANSI. Jeśli aplikacja Delphi sama kiedyś przeszła na Unicode, powstają hybrydowe stany: dane w starym kodowaniu, UI w Unicode, eksporty oczekujące Windows-1252. MariaDB powinna otrzymać jasne założenie (typowo utf8mb4), włącznie z rzetelną konwersją i testami wykrywającymi „niewidoczne” błędy (porównania, sortowanie, trim/pad, znaki specjalne).

4) „Puste” wartości, logika NULL i pola dat

Paradox/BDE zna różne szczególne przypadki: puste ciągi zamiast NULL, dane 0, „puste” znaczniki czasu, wartości domyślne generowane w UI. MariaDB rozróżnia rygorystycznie NULL i pusty string. Ma to wpływ na klauzule WHERE, agregacje i obliczenia. Różnice te trzeba ocenić dla każdej tabeli/pola.

5) Artefakty poboczne: tabele sesyjne, lokalna konfiguracja, cache

Często w strukturze Paradox znajdują się tabele lokalne dla wyników pośrednich, buforów eksportu, układów użytkownika czy parametrów. Część powinna pozostać lokalna (np. układy UI), inne elementy powinny być scentralizowane (np. zlecenia pracy, statusy, logi). Migracja to okazja, by te kategorie wyraźnie rozdzielić.

Pułapki Paradox/BDE: typowe różnice techniczne

Aby migrację zaplanować, warto wprost zaadresować powtarzające się różnice.

Dialekt SQL i operatory

SQL Paradox/BDE nie jest tożsamy z SQL MySQL/MariaDB. Różnice pojawiają się m.in. przy funkcjach daty, funkcjach na stringach, outer joinach (historycznie), logice Like/masek i przy implicznych konwersjach typów. Kontrolowane podejście zastępuje „działa jakoś” jasnymi regułami: które instrukcje portujemy, które świadomie przepisujemy, które kapsułujemy w widokach/procedurach składowanych (jeśli to sensowne)?

Sortowanie i collation

W Paradox porządek sortowania i rozróżnianie wielkości liter często różnią się od MariaDB, szczególnie w kontekście umlautów. W MariaDB o porównaniach i sortowaniu decyduje collation (np. utf8mb4_german2_ci vs. utf8mb4_unicode_ci). To nie jest kwestia akademicka: wpływa na deduplikację, funkcje wyszukiwania i zachowanie unikatowych constraintów.

Autoincrement i zakresy numeracji

Paradox posiada pola autoincrement, ale aplikacje często używają własnych zakresów numeracji (numery dokumentów, numeracje zleceń) ze specjalną logiką. W MariaDB powinno się wyraźnie rozdzielić:

• Techniczny klucz główny: AUTO_INCREMENT (lub UUID, w zależności od architektury) dla relacji.
• Numer fachowy: odrębny zakres numeracji z ochroną transakcyjną, ewentualnie per kontrahent/okres.

Kto próbuje użyć fachowego numeru jako technicznego klucza, naraża się później na kosztowne przeróbki.

Locking i transakcje

Przejście od dostępu plikowego do prawdziwego serwera to zysk, ale zmienia zachowanie. W MariaDB transakcje (InnoDB) są centralne. Trzeba zdecydować, gdzie leżą granice transakcyjne: na dialog, na zapis, na batch. Szczególnie istotne są długie transakcje i „tryb edycji” trwający minuty — w światach Paradox powszechne, na serwerze powodują problemy (blokady, deadlocki, lag replikacji). Dostrojenie sposobu pracy lub UI jest często częścią migracji.

Model postępowania: kontrolowana migracja etapami zamiast Big Bang

W środowiskach B2B stabilność operacyjna bywa ważniejsza niż szybkie przełączenie. Etapowa ścieżka migracji redukuje ryzyko, ponieważ dział biznesowy i IT mogą iteracyjnie weryfikować wyniki.

Etap 1: Transfer modelu danych z mapowaniem, bez przebudowy kodu

W pierwszym kroku buduje się schemat MariaDB odzwierciedlający strukturę Paradox — ale już według zasad docelowych: klucze podstawowe, indeksy, sensowne typy danych, utf8mb4, InnoDB. Równolegle tworzy się powtarzalny proces importu (skrypty/narzędzia), który można w razie potrzeby powtórzyć. Ważna jest powtarzalność, ponieważ migracja rzadko kończy się na pierwszym przebiegu.

Rezultaty tej etapy to zwykle:

• Wersjonowana definicja schematu (DDL) (np. w Git)
• Lista mapowania pól (Paradox → MariaDB) z regułami konwersji
• Procedura importu z logowaniem (liczba rekordów, błędy, odstępstwa)
• Pierwsze raporty walidacyjne (counts, sumy, checksums)

Etap 2: Eliminacja BDE w dostępie do danych (np. z użyciem FireDAC)

Rzeczywisty krok modernizacyjny to odseparowanie od BDE. W projektach Delphi BDE-Ablosung mit nativer Anbindung to sprawdzona droga, bo oferuje nowoczesne sterowniki, transakcje, wiązanie parametrów i zunifikowane komponenty dla różnych backendów SQL. Kluczowe nie jest „wyrzucenie BDE”, lecz jak kod będzie wyglądać dalej: centralny dostęp do danych, jasna obsługa błędów, czyste parametry zamiast konkatenacji stringów.

Typowe zadania w tej etapie:

• Zastąpienie TTable/TQuery przez zapytania i DataSety oparte na FireDAC
• Wprowadzenie warstwy dostępu do danych (DAL) jako bazy pod przyszłą Layer-3 architekturę
• Standaryzacja zakresów transakcyjnych (Commit/Rollback)
• Przegląd SQL: dostosowanie dialektu, parametry, stronicowanie, joiny

Jeśli aplikacja ma być modernizowana długoterminowo, ten krok bywa ważniejszy od samej migracji danych. Tworzy on techniczną swobodę dla 64‑bit, nowoczesnych wersji Windows i czystych pipeline’ów wdrożeniowych.

Etap 3: Równoległa praca i odbiór merytoryczny bez przerwy w działaniu

Dla krytycznych systemów sensowny jest tryb równoległy: MariaDB jest uruchamiana i cyklicznie (lub inkrementalnie) zasilana, podczas gdy system legacy dalej pracuje. Dzięki temu dział biznesowy może porównywać raporty, identyfikować przypadki brzegowe i testować nową platformę pod obciążeniem. Równoległość można zrealizować różnie:

• Repika tylko do odczytu do przygotowania raportów/BI
• „Dual-Write” w zdefiniowanych obszarach (tylko przy dobrym opanowaniu)
• Migracja na określony termin z kilkoma próbami i jasną listą kontrolną cutover

Ważne, by nie przesadzać złożoności: Dual-Write brzmi atrakcyjnie, ale jest podatny na błędy, jeśli logika fachowa nie jest zcentralizowana. Często bardziej opłacalny jest powtarzalny przebieg z ustalonym terminem i dobrą walidacją.

Etap 4: Optymalizacja, integralność, wydajność, procesy operacyjne

Po cutover rozpoczyna się faza, w której MariaDB powinna pokazać swoje zalety: integralność referencyjna, wydajne indeksy, czyste prawa, monitoring, testy backup/restore. W tym momencie często ujawniają się „prawdziwe” obciążenia produkcyjne: długie raporty, słabo indeksowane maski wyszukiwania, aktualizacje wsadowe. Kontrolowana migracja uwzględnia tę fazę w planie, zamiast pozostawiać ją jako nieplanowane poprawki.

Typy danych i mapowanie: z Paradox do MariaDB bez utraty informacji

Mapowanie pól to serce migracji. Typowe przyporządkowania (upraszczając) to:

• Alpha / Memo: VARCHAR/TEXT (z utf8mb4), walidacja długości i reguły trim
• Number: INT/BIGINT/DECIMAL w zależności od zakresu wartości; uwaga na impliczne miejsca po przecinku
• Date/Time: DATE/DATETIME/TIMESTAMP; jasne reguły dla „daty 0” versus NULL
• Logical: BOOLEAN lub TINYINT(1) z jednoznaczną semantyką
• Currency: DECIMAL(…,2/4) zamiast float, aby uniknąć błędów zaokrągleń

Ważne jest nie tylko tłumaczenie typów danych, ale też zapisanie reguł fachowych: Czy pole może być NULL? Jakie wartości domyślne są merytorycznie poprawne? Które kombinacje muszą być unikalne? Z tego wynikają constraints i indeksy. Reguły te w systemie Paradox/BDE często były ukryte w UI lub w kodzie — w MariaDB powinny tam, gdzie to sensowne, stać się eksplicytne.

Integralność: wprowadzenie Primary Keys, Foreign Keys i indeksów unikalnych

Wiele baz legacy funkcjonuje latami bez integralności referencyjnej — aż do momentu, gdy pojawiają się integracje, portale lub procesy równoległe. Wtedy jakość danych staje się ograniczeniem. W MariaDB można zastosować Foreign Keys, Unique Constraints i CHECK (w zależności od wersji/silnika), aby wcześniej wykrywać błędy danych.

Praktyczne podejście to stopniowe wprowadzanie integralności:

• Najpierw klucze podstawowe i unikalne indeksy na obiektach podstawowych (klienci, artykuły, dokumenty)
• Następnie Foreign Keys w stabilnych obszarach
• Dla tabel „historycznych” z zasobami nieczystymi: najpierw oczyszczenie danych, potem constraints

To zmniejsza ryzyko, że cutover zawiedzie z powodu starych zaległości, a jednocześnie znacząco poprawia sytuację.

Wydajność w praktyce: co się zmienia z MariaDB

Systemy Paradox/BDE często były zoptymalizowane pod „szybkość plikową”: lokalne indeksy, szybkie odczyty tabel, dużo filtrowania po stronie klienta. W MariaDB obciążenie przenosi się na serwer. To korzystne, ale wymaga przemyślanego SQL i strategii indeksowania.

Typowe pułapki wydajnościowe

• SELECT * z dużych tabel, bo wcześniej „lokalnie” było wystarczająco szybko
• Filtrowanie po stronie klienta zamiast klauzul WHERE po stronie serwera
• Brak złożonych indeksów dla pól wyszukiwania (np. mandant + status + data)
• LIKE ‚%tekst%‘ bez odpowiedniej strategii pełnotekstowej

Poprawa mierzalna zamiast „na wyczucie”

Kontrolowana migracja ustanawia wcześnie punkty pomiarowe: Slow Query Log, analizy EXPLAIN, powtarzalne testy obciążeniowe. To szczególnie ważne, gdy po migracji planowane są kolejne komponenty, np. REST-serwer lub portal klienta, które generują nowe wzorce dostępu (wiele małych żądań, stronicowanie, endpointy wyszukiwania).

Specyfika Delphi: eliminacja BDE, FireDAC i czyste warstwy dostępu

W projektach Delphi modernizacja techniczna jest ściśle powiązana z dostępem do danych. BDE to nie tylko „sterownik”, lecz cały styl dostępu (TTable, dostęp rekordowy, nawigacja, lokalne filtry). Migracja do MariaDB to właściwy moment, by skonsolidować ten dostęp.

Z „DataSetów wszędzie” do kontrolowanego dostępu do danych

Wielu aplikacjom towarzyszy sytuacja, że w każdym formularzu znajdują się własne zapytania. To źle skaluje pod względem fachowym i bezpieczeństwa. Sprawdza się przejście w kierunku:

• Centralnych klas repository/service dla obiektów kluczowych
• Jednolitej obsługi błędów i transakcji
• Parametryzowanych zapytań (uniknięcie SQL Injection, wykorzystanie cache planów)
• Konfigurowalnych puli połączeń lub zarządzania połączeniami w usługach

To tworzy podstawę pod Layer-3 architekturę, w której UI, logika fachowa i trwałe przechowywanie są wyraźnie rozdzielone. Pomaga to nie tylko przy zmianie bazy, lecz także przy późniejszym rozwoju w kierunku REST-serwerów lub usług backgroundowych.

Podłączenie MariaDB z FireDAC: co zwykle trzeba ustalić

W projektach pojawiają się wciąż te same pytania: która odmiana sterownika (MySQL/MariaDB), jakie opcje SSL, jakie ustawienia strefy czasowej i dat, jakie ustawienia Unicode? To nie są drobiazgi, bo wpływają bezpośrednio na spójność danych (data/czas), sortowanie i bezpieczeństwo operacyjne (TLS). Kontrolowana migracja ustala te parametry, dokumentuje je i testuje na realistycznych danych.

Plan przełączenia: termin, zamrożenie danych, rollback — bez niespodzianek

Cutover to projekt sam w sobie. Dobry plan przełączenia opisuje nie tylko „kiedy zmieniamy”, ale też środki ochronne:

• Zamrożenie danych: od kiedy w systemie legacy nie będą już rejestrowane dane? Czy istnieją procesy awaryjne?
• Finalny import: Ile realnie trwa? (suchy przebieg daje liczby.)
• Walidacja: Które checki muszą być zielone przed akceptacją (liczniki, sumy, próbki, raporty fachowe)?
• Rollback: Kiedy przerywamy i jak dalej postępujemy?
• Komunikacja: Kto zatwierdza? Kto jest dostępny w war roomie?

Szczególnie w średnich przedsiębiorstwach „rollback” często jest krytyczny nie technicznie, lecz organizacyjnie. Dlatego migracja musi być przygotowana tak, by cutover nie był eksperymentem, lecz przećwiczonym przebiegiem.

Po migracji: baza pod REST, usługi i multiplatformę

Gdy MariaDB działa stabilnie, a eliminacja BDE została poprawnie wykonana, otwierają się nowe opcje: REST-API dla systemów zewnętrznych, przetwarzanie tła jako Windows- lub Linux-usługi, odseparowanie UI od logiki fachowej oraz perspektywa klientów multiplatformowych. Często następnym krokiem jest wyciągnięcie logiki fachowej z desktopu, by kontrolowanie obsługiwać integracje (ERP/DMS/CRM) i portale.

Ważne: REST-serwer to nie „dodatkowa warstwa”, lecz decyzja architektoniczna. Kto już scentralizował dostęp do danych, walidacje i uprawnienia w usługach/repository, może znacznie łatwiej budować stabilne API.

Lista kontrolna praktyczna: co wyjaśnić przed startem projektu

• Które moduły są krytyczne dla biznesu i muszą działać na dzień przełączenia?
• Jak wyglądają rzeczywiste wolumeny danych (rozmiary tabel, wzrost, koncepcje archiwizacji)?
• Które raporty muszą być identyczne 1:1, które mogą być poprawione?
• Jakie integracje zależą od systemu (eksporty plików, ODBC, Office, ścieżki drukowania)?
• Czy istnieje obsługa wielodostępności/multi-tenant, a jeśli tak — jak jest obecnie odwzorowana?
• Jakie wymagania operacyjne obowiązują (okna backupu, czas przywracania, uprawnienia, audyt)?

Te ustalenia to nie biurokracja, lecz zapobieganie sytuacji, w której migracja jest „technicznie zakończona”, ale merytorycznie nieprzyjęta.

Wniosek: kontrolowana migracja to planowanie ryzyk

Kontrolowana migracja Paradox i BDE do MariaDB oznacza modernizację aplikacji jako systemu całościowego: model danych, SQL, transakcje, zestawy znaków, warstwa dostępu i procesy operacyjne. Kto traktuje zmianę jako zwykły eksport, zwykle trafia na te same problemy, których chciał się pozbyć — tylko na nowym serwerze.

Etapowe podejście z powtarzalnym importem, rzetelnym mapowaniem pól, wczesną walidacją i jasną eliminacją BDE (np. przez FireDAC) daje natomiast stabilną podstawę: dla wielodostępu, integracji, usług i kolejnych kroków w Delphi modernizacji.

Jeśli chcą Państwo merytorycznie zaplanować migrację i zrealizować ją bez przerwy w działaniu, chętnie omówimy stan wyjściowy, ryzyka i realistyczny plan etapowy: https://net-base-software-gmbh.de/kontakt/