Paradox- ja BDE-tietokantojen hallittu migraatio MariaDB:hen

Monet Delphi-toimialasovellukset on syntetisoitu Paradox-taulukoilla ja Borland Database Enginella (BDE), koska se oli aikanaan käytännöllinen standardi: paikallinen, nopeasti käyttövalmis, vähän infrastruktuuria. Käytännössä nämä järjestelmät usein toimivat tuotannossa vieläkin – mukaan lukien raportointi, etikettitulostus, import/export, batch-työt, historiataulut ja erikoislogiikka, joka on vuosien aikana „työstynyt” tietokantakäyttöön. Siksi migrointi ei ole pelkkä datan vienti, vaan kontrolloitu uudelleenrakennus: tietomalli, SQL-käyttäytyminen, koodin sivuvaikutukset ja toimintaprosessit on arvioitava yhdessä.

MariaDB on kohdealustana usein hyvä valinta, kun tarvitaan vakaata monikäyttäjäkäyttöä, puhtaita transaktioita, keskitettyjä varmuuskopioita, replikaatiota, selkeää oikeushallintaa ja liitettävyyttä web-portaaleihin, palveluihin tai REST-API:hin. Haaste ei yleensä ole tietokannan asennus – varsinainen työ on turvallinen migraatiopolku: miten taulut, indeksit, primary keyt, merkistöt, päivämääräkentät, „tyhjät” arvot ja referenssisuhteet viedään oikein ilman, että liiketoimintalogiikka rikkoontuu tuotantokäytössä?

Tämä kirjoitus kuvaa vakiintunutta lähestymistapaa Paradox- ja BDE-järjestelmien kontrolloituun siirtoon MariaDB:hen: teknisesti perusteltu, vaiheittainen ja vakauteen keskittyvä. Tavoitteena on kestävä perusta jatkotoimenpiteille – esimerkiksi BDE-poisto, siirtymä BDE-Ablösung mit nativer Anbindung, selkeä Layer-3-arkkitehtuuri, REST-palvelimet ja alustariippumattomat clientit.

Miksi Paradox/BDE-migraatio on enemmän kuin pelkkä tietokantavaihto

Paradox-tiedostoformaatti ja BDE-käyttökerros muodostavat kokonaisjärjestelmän, jonka erityispiirteitä ei kannata 1:1 jäljentää MariaDB:ssä. Tyypillisiä arjen oireita ovat:

• Läpinäkymättömät riippuvuudet: SQL-lauseet ovat hajautettuina (Forms, DataModules, Reports, dynaamiset String-SQL:t), usein ilman keskitettyä hallintaa.
• Käyttäytyminen „tuntemuksen varassa“: tietyt suodattimet, lajittelut tai joinit toimivat sattumalta, koska Paradox/BDE on tolerantti tai tekee implisiittisiä tyyppimuunnoksia.
• Monikäyttäjärajat: tiedostopohjaiset lukitukset, suorituskyvyn heikentyminen verkossa, lock-ongelmat kasvavassa datamäärässä.
• Ylläpidon riskit: BDE-riippuvuudet, vanhat ajurit, hankala käyttöönotto moderneilla Windows-versioilla, 64‑bit/ARM64-aiheiset haasteet.

Kontrolloitu migraatio ei käsittele näitä kohtia sivuvaikutuksina, vaan asettaa ne hyväksymiskriteereiksi. MariaDB ei siten ole vain „uusi tietokanta“, vaan mahdollisuus irrottaa datan käyttökerros, parantaa liiketoimintaintegraatiota ja luoda selkeät rajapinnat.

Tavoitenäkymä: MariaDB vakaana tietopohjana desktopille, palveluille ja portaalille

Järkevä tavoitenäkymä B2B-toimialasovelluksille rakentuu useimmiten kolmesta tasosta:

• Tietokanta (MariaDB): konsistentti tietovarasto, indeksit, constraints, transaktiot, käyttäjät/roolit, varmuuskopioinnit.
• Liiketoimintalogiikka (Server/Services): validoinnit, workflowit, importterit, ajastimet, rajapinnat. Valinnaisesti REST-server, Windows- tai Linux-palvelut.
• Clientit (VCL/FMX/Web): käyttöliittymät, raportit, offline-osat, integraatiot. Idealisti selkeillä sopimuksilla liiketoimintalogiikasta.

Riippuen lähtökohdasta kaikkea ei tarvitse toteuttaa heti. Migraation tulee kuitenkin suunnitella siten, että se ei estä siirtymistä puhtaaseen arkkitehtuuriin. Jos tänään vain kopioidaan taulut ja huomenna taas jokaisesta lomakkeesta kirjoitetaan „suoraan“ tietokantaan, MariaDB on kyllä käytössä, mutta todelliset riskit säilyvät.

Tilannekartoitus: Mitä todella pitää migroida

Aluksi tehdään inventaario, joka menee „kuinka monta taulua“ -kysymyksen ohi. Paradox/BDE-projekteissa on tyypillistä, että tietokanta on vain osa totuutta. Tärkeitä kohtia:

1) Taulut, indeksit, „pseudo-avaimet“

Usein puuttuu oikeita Primary Key -kenttiä. Sen sijaan on kenttäyhdistelmiä, juoksevia numeroita ilman yksilöivää constraintia tai „Key“-kenttiä, joita sovellus ylläpitää. MariaDB:ssä näistä täytyy muodostaa yksilöllisiä, luotettavia avaimia – muutoin transaktiot ja referentiaalinen eheys toimivat vain rajoitetusti.

2) Kyselyt, dynaamiset SQL-komponentit, raportit

BDE käyttää komponentista riippuen erilaisia SQL-dialekteja ja sallii „luovia“ lauseita. Raportointikomponenteissa (myös vanhemmissa) on usein omia SQL-määrittelyjä. Migraation on löydettävä ja luokiteltava nämä lähteet: kriittiset ydinqueries, harvoin käytetyt analyysit, erikoisimportit.

3) Merkistöt ja erikoismerkit (umlautit, ISO/ANSI, Unicode)

Monet Paradox-sovellukset ovat historiallisesti ANSI-pohjaisia. Jos Delphi-sovellus on jossain vaiheessa siirtynyt Unicodeen, syntyy sekoitustilanteita: data on vanhassa enkoodauksessa, UI on Unicode, exportit odottavat Windows-1252:ta. MariaDB:lle pitäisi määritellä selkeä konsepti (tyypillisesti utf8mb4), mukaan lukien huolellinen konversio ja testit „näkymättömien“ virheiden varalta (vertailut, lajittelu, trim/pad, erikoismerkit).

4) „Tyhjät“ arvot, NULL-logiikka ja päivämääräkentät

Paradox/BDE tuntee useita erityistapauksia: tyhjät merkkijonot NULL:in sijaan, 0-arvot, „tyhjät“ timestampit, oletusarvot, jotka syntyvät käyttöliittymässä. MariaDB erottaa tiukasti NULL:n ja tyhjän arvon. Tämä vaikuttaa WHERE-lauseisiin, aggregointeihin ja laskentaan. Erot on arvioitava taulu/kenttäkohtaisesti.

5) Sivutuotteet: Session-taulut, paikallinen konfiguraatio, välimuisti

Usein Paradox-rakenteessa on paikallisia tauluja välituloksille, export-puskurille, käyttäjäkohtaisille näkymille tai parametreille. Osa kuuluu jatkossakin paikallisesti säilytettäväksi (esim. UI-näkymät), osa kuuluu keskitettyyn tallennukseen (esim. työprosessit, tilat, lokit). Migraatio on tilaisuus erottaa nämä kategoriat selkeästi.

Karikot Paradox/BDE-maailmassa: tyypilliset tekniset erot

Migraation suunniteltavuuden kannalta on hyödyllistä käsitellä toistuvia eroja eksplisiittisesti.

SQL-dialekti ja operaattorit

BDE/Paradox-SQL ei ole identtinen MySQL/MariaDB-SQL:n kanssa. Eroja esiintyy mm. päivämääräfunktioissa, merkkifunktioissa, outer-joinien käsittelyssä (historiallisesti), Like/Mask-logiikassa ja implisiittisissä tyyppimuunnoksissa. Kontrolloitu lähestymistapa korvaa „toimii jotenkin“ -asenteen selkeillä säännöillä: mitkä lauseet siirretään, mitkä kirjoitetaan uudelleen, mitkä kapseloidaan vieweihin/stored procedureihin (jos järkevää)?

Lajittelu ja collatio

Paradoxissa lajittelujärjestykset ja iso/pieni-kirjainherkkyys voivat poiketa MariaDB:stä, erityisesti umlauttien suhteen. MariaDB:ssä collation (esim. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) määrää vertailun ja lajittelun. Tämä ei ole teoreettinen seikka: se vaikuttaa deduplikaatioon, hakutoimintoihin ja Unique-constraintien käyttäytymiseen.

Autoincrement ja numerokäytännöt

Paradoxissa on autoincrement-kenttiä, mutta sovellukset käyttävät usein omia numerokäytäntöjä (tositenumero, tilausnumero) erityislogiikalla. MariaDB:ssä kannattaa erottaa:

• Tekninen primääriavain: AUTO_INCREMENT (tai UUID, arkkitehtuurista riippuen) relaatioksi.
• Asiakirjanumero: oma numerokäytäntö transaktiosuojauksella, mahdollisesti per tenant/per periode.

Kuka tahansa, joka yrittää käyttää liiketoimintatunnusta teknisenä avaimena, kohtaa myöhemmin kalliita muutostöitä.

Lukitus ja transaktiot

Siirtyminen tiedostopohjaisesta käytöstä palvelinarkkitehtuuriin on etu, mutta muuttaa käyttäytymistä. MariaDB:ssä transaktiot (InnoDB) ovat keskeisiä. On päätettävä, missä transaktion rajat kulkevat: per dialogi, per tallennus, per batch. Erityisen tärkeää: pitkät transaktiot ja „muokkaustila“ minuuttien ajan ovat Paradox-ympäristöissä yleisiä, mutta palvelinpuolella riskialttiita (lockit, deadlockit, replikaation viive). Tässä usein vaaditaan työnkulun tai UI:n mukautusta osana migraatiota.

Menetelmä: kontrolloitu migraatio vaiheittain Big Bangin sijaan

B2B-ympäristöissä toimintavarmuus on usein tärkeämpää kuin nopea leikkaus. Vaiheittainen migrointipolku vähentää riskiä, koska liiketoiminta ja IT voivat iteratiivisesti validoida.

Vaihe 1: tietomallin siirto mappingilla, ilman koodin uudelleenjärjestelyä

Ensimmäisessä vaiheessa rakennetaan MariaDB-skeema, joka mallintaa Paradox-rakennetta – mutta jo tavoiteperiaatteilla: Primary Keyt, indeksit, tarkoituksenmukaiset tietotyypit, utf8mb4, InnoDB. Samanaikaisesti luodaan toistettavissa oleva import-prosessi (skriptit/työkalut), jota voi tarvittaessa ajaa uudelleen. Toistettavuus on tärkeää, koska migraatio ei yleensä onnistu kerralla.

Tämän vaiheen toimitukset ovat tyypillisesti:

• Skeeman määrittely (DDL) versionoituna (esim. Gitissä)
• Kenttämapping-lista (Paradox → MariaDB) sisältäen konversiosäännöt
• Import-proseduuri lokituksella (rivit, virheet, poikkeamat)
• Ensimmäiset validointiraportit (counts, summat, tarkistesummat)

Vaihe 2: BDE-poisto datan käytöstä (esim. FireDAC avulla)

Varsinainen modernisointiaste on BDE:n irrottaminen. Delphi-projekteissa BDE-Ablosung mit nativer Anbindung on vakiintunut reitti, koska se tarjoaa moderneja ajureita, transaktiotuen, parametrin sitomisen ja yhtenäiset komponentit eri SQL-backendeille. Oleellista ei ole pelkkä „BDE pois“, vaan se, miltä koodi näyttää sen jälkeen: keskitetty datan käyttö, selkeä virheenkäsittely, puhtaat parametrit eivätkä string-konkatenoinnit.

Tyypillisiä tehtäviä tässä vaiheessa:

• TTable/TQuery:n korvaaminen FireDAC-Queries ja DataSeteillä
• Data-Access-kerroksen (DAL) käyttöönotto pohjaksi tulevalle Layer-3-arkkitehtuurille
• Transaktiorajojen standardisointi (Commit/Rollback)
• SQL-katselmointi: dialektin sovitus, parametrit, sivutus, joinit

Jos sovellus on tarkoitus modernisoida pitkällä tähtäimellä, tämä vaihe on usein tärkeämpi kuin pelkkä datan siirto. Se luo teknisen vapauden 64‑bitille, moderneille Windows-versioille ja selkeille deployment-putkille.

Vaihe 3: rinnakkaisajo ja liiketoiminnallinen hyväksyntä ilman katkoksia

Kriittisissä järjestelmissä rinnakkaisajo on järkevä: MariaDB rakennetaan ja täytetään syklisesti (tai inkrementaalisesti), kunnes vanha järjestelmä jatkaa toimintaansa. Näin liiketoiminta voi verrata tuloksia, tunnistaa reunatapaukset ja testata uutta alustaa kuormituksessa. Rinnakkaisajo voidaan toteuttaa eri tavoilla:

• Read-only-replika raportointia/BI-valmistelua varten
• „Dual write“ määritellyissä osa-alueissa (vain jos hallinnassa)
• Leikkauspäivämigraatio useilla kuivaharjoituksilla ja selkeällä cutover-checklistalla

Tärkeää on olla lisäämättä liiallista monimutkaisuutta: Dual-Write kuulostaa houkuttelevalta, mutta on virherikas, jos liiketoimintalogiikka ei ole keskitetty. Usein toistettava stichtags-luonti hyvällä validoinnilla on taloudellisesti järkevämpi.

Vaihe 4: optimointi, eheys, suorituskyky, operointiprosessit

Cutoverin jälkeen alkaa vaihe, jossa MariaDB voi näyttää vahvuutensa: referentiaalinen eheys, tehokkaat indeksit, selkeät oikeudet, monitoring, backup/restore-testit. Tässä vaiheessa näkyvät usein vasta „todelliset“ tuotantokuormat: pitkät raportit, huonosti indeksoidut hakunäkymät, batch-päivitykset. Kontrolloitu migraatio suunnittelee tämän vaiheen eksplisiittisesti sen sijaan, että jättää sen odottamattomaksi jälkityöksi.

Tietotyypit ja mapping: Paradoxista MariaDB:hen ilman tietohäviötä

Kenttämapping on migraation ydin. Tyypillisiä vastineita (yksinkertaistettuna) ovat:

• Alpha / Memo: VARCHAR/TEXT (utf8mb4), pituustarkistus ja trim-säännöt
• Number: INT/BIGINT/DECIMAL riippuen arvoalueesta; varovaisuus implisiittisten desimaalien kanssa
• Date/Time: DATE/DATETIME/TIMESTAMP; selkeät säännöt „0-päivämäärälle“ vs. NULL
• Logical: BOOLEAN tai TINYINT(1) yksiselitteisellä semantiikalla
• Currency: DECIMAL(…,2/4) floatin sijaan pyöristysvirheiden välttämiseksi

On tärkeää olla vain kääntämättä tietotyyppejä, vaan myös dokumentoida liiketoimintasäännöt: Saako kenttä olla NULL? Mitkä oletusarvot ovat liiketoiminnallisesti oikeita? Mitkä kenttäyhdistelmät on oltava yksilöllisiä? Näistä seuraavat constraintit ja indeksit. Nämä säännöt olivat Paradox/BDE-järjestelmässä usein implisiittisiä käyttöliittymässä tai koodissa – MariaDB:ssä ne tulisi, missä järkevää, tehdä eksplisiittisiksi.

Eheys: Primary Keyt, Foreign Keyt ja uniikit indeksit

Monet legacy-tietokannat ovat toimineet vuosia ilman referentiaalista eheyttä – kunnes integraatiot, portaalit tai rinnakkaiset prosessit tulevat kuvaan. Silloin datalaatu muodostuu rajoitteeksi. MariaDB:ssä voi ottaa käyttöön Foreign Keyt, Unique Constraints ja Checkit (versiosta/enginestä riippuen) estämään datavirheitä varhaisessa vaiheessa.

Käytännöllinen polku on ottaa eheys käyttöön vaiheittain:

• Ensin Primary Keyt ja uniikit indeksit ydinkohteille (asiakkaat, artikkelit, dokumentit)
• Sitten Foreign Keyt vakailla alueilla
• Historiallisille tauluille, joissa dataroskkaa: ensin siivous, sitten constraintit

Tämä vähentää riskiä, että cutover epäonnistuu vanhoihin jäänteisiin ja parantaa silti kokonaiskuvaa merkittävästi.

Suorituskyky käytännössä: mitä MariaDB muuttaa

Paradox/BDE-järjestelmät on usein optimoitu „tiedostonopeudelle“: paikalliset indeksit, nopea taulukkokäyttö, paljon client-puolista suodatusta. MariaDB:ssä työ siirtyy palvelimelle. Se on positiivista, mutta edellyttää puhtaita SQL- ja indeksi-strategioita.

Tyypilliset suorituskykyansat

• SELECT * suurista tauluista, koska aiemmin „paikallinen“ riitti
• Client-puolinen suodatus serverin WHERE:n sijaan
• Puutteelliset yhdistetyt indeksit hakunäkymien kentille (esim. tenant + status + päivämäärä)
• LIKE ‚%teksti%‘ ilman sopivaa täystekstistrategiaa

Mitoitettavissa parannuksia, ei „tuntemuksella“

Kontrolloitu migraatio asettaa varhain mittarit: Slow Query Log, EXPLAIN-analyysit, toistettavat kuormitustestit. Tämä on erityisen tärkeää, jos migraation jälkeen suunnitellaan lisäkomponentteja kuten REST-palvelinta tai asiakasportaalia, jotka tuovat uusia käyttömalleja (monta pientä pyyntöä, sivutus, hakupisteet).

Delphi-kohtaiset seikat: BDE-poisto, FireDAC ja puhtaat käyttökerrokset

Delphi-projekteissa tekninen modernisointi on tiukasti sidoksissa datan käyttöön. BDE ei ole vain „ajuri“, vaan kokonainen käyttötyyli (TTable, tietuepohjainen käsittely, navigointi, paikalliset suodatukset). Siirtyminen MariaDB:hen on oikea hetki konsolidoida pääsylokit.

DataSeteistä kontrolloituun datan käyttöön

Monissa sovelluksissa jokaisella lomakkeella on omat querynsä. Se ei skaalaudu toiminnallisesti tai turvallisuuden kannalta. Hyvä käytäntö on siirtyä kohti:

• Keskitettyjä repository-/service-luokkia ydinobjekteille
• Yhtenäistä virhe- ja transaktiohandlausta
• Parametrisoituja kyselyitä (SQL injectionin välttäminen, plan-cachingin hyödyntäminen)
• Konfiguroitavia connection-pooleja tai yhteyshallintaa palveluille

Tämä luo pohjan Layer-3-arkkitehtuurille, jossa UI, liiketoimintalogiikka ja persistenssi ovat selkeästi erillään. Se auttaa paitsi tietokantavaihtoa, myös myöhempää siirtymää kohti REST-palvelimia tai taustaprosesseja.

MariaDB-yhteys FireDAC:n kautta: yleensä selvitettävät asiat

Projekteissa nousee toistuvasti samoja kysymyksiä: mikä ajuriversio (MySQL/MariaDB), mitkä SSL-valinnat, timezone- ja päivämääräasetukset, unicode-asetukset? Nämä eivät ole pikkuseikkoja, sillä niillä on suora vaikutus datakonsistenssiin (aika), lajitteluun ja tuotantoturvallisuuteen (TLS). Kontrolloitu migraatio määrittelee nämä parametrit, dokumentoi ne ja testaa realistisella datalla.

Cutover-suunnitelma: päivämäärä, datafreeze, rollback – ilman yllätyksiä

Cutover on itsenäinen projekti. Hyvä cutover-suunnitelma kuvaa muutakin kuin „milloin vaihdetaan“, se sisältää suojaustoimet:

• Datafreeze: Minkä hetkestä lähtien vanhassa järjestelmässä ei tallenneta? Onko varaprosesseja?
• Viimeinen import: Kuinka kauan se realistisesti kestää? (Kuivaharjoitukset antavat luvut.)
• Validointi: Mitkä tarkistukset on oltava vihreitä ennen hyväksyntää (counts, summat, otantatarkistukset, liiketoimintaraportit)?
• Rollback: Milloin keskeytetään ja miten edetään sen jälkeen?
• Kommunikointi: Kuka antaa hyväksynnän? Kuka on paikalla War Roomissa?

Erityisesti keskisuurissa yrityksissä „rollback“ on usein organisatorinen, ei tekninen haaste. Siksi migraatio on valmisteltava siten, että cutover ei ole koeajettava operaatio, vaan harjoiteltu prosessi.

Migration jälkeen: perusta REST:lle, palveluille ja monialustaisuudelle

Kun MariaDB toimii vakaasti ja BDE-poisto on tehty huolellisesti, avautuu uusia mahdollisuuksia: REST-API:t ulkoisille järjestelmille, taustankäsittely Windows- tai Linux-palveluina, UI:n ja liiketoimintalogiikan irrottaminen sekä pitkällä tähtäimellä monialustaiset clientit. Yleinen seuraava askel on usein liiketoimintalogiikan siirtäminen desktopista, jotta integraatiot (ERP/DMS/CRM) ja portaalit voidaan palvella kontrolloidusti.

Tärkeää: REST-palvelin ei ole vain „lisäkerros“, vaan arkkitehtuuripäätös. Kuka tahansa, joka on jo konsolidoinut datan käytön, validoinnit ja oikeudet palveluihin/repositoryihin, pystyy rakentamaan kestäviä rajapintoja huomattavasti helpommin.

Praktiikan tarkistuslista: mitä selvittää ennen projektin käynnistystä

• Mitkä moduulit ovat liiketoiminnallisesti kriittisiä ja niiden on toimittava varmuudella cutover-päivänä?
• Mitä todelliset datamäärät ovat (taulujen koot, kasvu, arkistointikäytännöt)?
• Mitkä raportit on oltava 1:1 identtisinä ja mitkä voidaan parantaa?
• Mitkä integraatiot riippuvat järjestelmästä (tiedostoviennit, ODBC, Office, tulostusputket)?
• Onko järjestelmä moniyritys/tenant-kyvykäs, ja jos on: miten se on toteutettu nykyisin?
• Mitkä operointivaatimukset pätevät (backup-ikkuna, restore-aika, oikeudet, auditointi)?

Nämä selvitykset eivät ole byrokratiaa, vaan estävät sen, että migraatio on teknisesti valmis mutta ei liiketoiminnallisesti hyväksytty.

Yhteenveto: kontrolloitu migrointi tarkoittaa riskien hallintaa

Paradoxin ja BDE:n kontrolloitu siirto MariaDB:hen merkitsee sovelluksen modernisointia kokonaisuutena: tietomalli, SQL, transaktiot, merkistöt, käyttökerros ja operointiprosessit. Kuka tahansa, joka pitää muuttoa pelkkänä exporttina, saa usein ne samat ongelmat, joista oli tarkoitus päästä eroon – vain uudella palvelimella.

Vaiheittainen lähestymistapa toistettavalla importilla, huolellisella kenttämappingilla, aikaisella validoinnilla ja selkeällä BDE-poistolla (esim. FireDAC) luo vakaamman perustan: monikäyttäjäkäytölle, integraatioille, palveluille ja seuraaville Delphi-modernisoinnin askelmille.

Jos haluat suunnitella migraation liiketoiminnallisesti turvallisesti ja ilman käyttökatkoksia, käsittelemme mielellämme lähtötilanteen, riskit ja realistisen vaiheistuksen: https://net-base-software-gmbh.de/kontakt/