Paradox ve BDE'yi kontrollü olarak MariaDB'ye geçirmek

Birçok Delphi uzmanlık uygulaması, o zamanlar pragmatik bir standart olduğu için Paradox tabloları ve Borland Database Engine (BDE) ile oluşturulmuştur: yerel, hızlı kullanıma hazır, az altyapı gerektiren. Pratikte bu sistemler çoğunlukla bugün hâlâ üretimde çalışıyor – raporlama, etiket baskısı, ithalat/ihracat, batch işleri, tarihçe tabloları ve yıllar içinde veri erişimine “yedirilmiş” özel mantıklar dahil. Bu nedenle bir göç yalnızca verilerin dışa aktarılması değil, kontrollü bir yeniden inşa işlemidir: veri modeli, SQL davranışı, koddaki yan etkiler ve işletme süreçleri birlikte ele alınmalıdır.

MariaDB, çok kullanıcılı sağlam işletim, tutarlı işlemler, merkezi yedeklemeler, replikasyon, net hak yönetimi ve web portalları, servisler veya REST-API’lere bağlantı kabiliyeti açısından hedef platform olarak sıkça iyi bir seçimdir. Zorluk nadiren veritabanı kurulumudur – asıl çaba güvenli bir geçiş yolunda yatar: Tablolar, indeksler, birincil anahtarlar, karakter setleri, tarih alanları, “boş” değerler ve referans ilişkiler, çalışma zamanında iş mantığı bozulmadan nasıl doğru aktarılır?

Bu yazı, Paradox ve BDE’nin MariaDB’ye kontrollü göçü için kanıtlanmış bir yaklaşımı tanımlar: teknik olarak sağlam, kademeli ve stabilite odaklı. Amaç, örneğin BDE‑nin kaldırılması, yerel bağlantıyla BDE-Ablösung, net bir Layer-3 Architektur, REST-Server ve platform-uyumlu istemciler gibi ileriki modernizasyon adımları için sağlam bir temel oluşturmaktır.

Warum Paradox/BDE-Migration mehr ist als ein Datenbankwechsel

Paradox dosya formatı ve BDE erişim katmanı, MariaDB’de birebir “yeniden inşa” edilmemesi gereken kendine özgü bir bütün sistem oluşturur. Günlük kullanımda tipik belirtiler şunlardır:

• Şeffaf olmayan bağımlılıklar: SQL ifadeleri dağıtılmıştır (Forms, DataModules, Reports, dinamik string‑SQL), genellikle merkezi bir yönetişim olmadan.
• “Hissettiği gibi” davranış: Belirli filtreler, sıralamalar veya join’ler tesadüfen çalışır; çünkü Paradox/BDE hoşgörülüdür veya örtük tip dönüşümleri yapar.
• Çok kullanıcılı sınırlamalar: Dosya tabanlı kilitlemeler, ağ üzerinde performans düşüşleri, artan veri hacminde locking sorunları.
• Bakım riskleri: BDE bağımlılıkları, eski sürücüler, modern Windows sürümlerinde zorlu dağıtım, 64‑Bit/ARM64 konuları.

Kontrollü bir göç bu noktaları yan etki olarak değil, hedef kriterleri olarak ele alır. MariaDB yalnızca “yeni veritabanı” olmakla kalmaz; veri erişim katmanını ayırma, işsel bütünlüğü artırma ve arayüz yetenekleri sağlama fırsatı sunar.

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

B2B uzmanlık uygulamaları için makul bir hedef resim genellikle üç katmandan oluşur:

• Veritabanı (MariaDB): tutarlı veri saklama, indeksler, kısıtlar, işlemler, kullanıcı/roller, yedeklemeler.
• İş mantığı (Server/Services): validasyonlar, iş akışları, importer’lar, zamanlayıcılar, arayüzler. Opsiyonel olarak bir REST-Server, Windows- veya Linux-Services olarak uygulanabilir.
• İstemciler (VCL/FMX/Web): kullanıcı arayüzleri, raporlar, çevrimdışı parçalar, entegrasyonlar. İdeal olarak iş mantığına yönelik net sözleşmeler ile.

Başlangıç durumuna bağlı olarak her şeyin hemen uygulanması gerekmez. Ancak göç, temiz bir mimariye giden yolu tıkamayacak şekilde planlanmalıdır. Bugün sadece tabloları kopyalayıp yarın her formdan “doğrudan” veritabanına yazmaya devam edenler MariaDB’yi getirmiş olsalar bile esas riskler olduğu yerde kalır.

Bestandsaufnahme: Was wirklich migriert werden muss

Başlangıçta “kaç tablo” sorusunun ötesine geçen bir envanter yapılmalıdır. Paradox/BDE projelerinde veritabanı genellikle bütün gerçeğin sadece bir parçasıdır. Önemli noktalar:

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

Gerçek Primary Key’ler sıklıkla eksiktir. Bunun yerine alan kombinasyonları, benzersiz kısıt olmadan yürütülen sıra numaraları veya uygulama tarafından yönetilen “Key” alanlar bulunur. MariaDB için bunlardan benzersiz, güvenilir anahtarlar oluşturulmalıdır – aksi halde işlemler ve referans bütünlüğü sınırlı etki gösterir.

2) Queries, dynamische SQL-Bausteine, Reports

BDE kullandığı bileşene göre farklı SQL diyalektleri kullanır ve “yaratıcı” ifadeleri tolere eder. Raporlama bileşenleri (eski olanlar dahil) sıklıkla kendi SQL tanımlarını içerir. Bir göç bu kaynakları bulmalı ve kategorize etmelidir: kritik çekirdek sorgular, nadiren kullanılan analizler, özel importlar.

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

Birçok Paradox uygulaması tarihsel olarak ANSI tabanlıdır. Eğer Delphi uygulaması zaman içinde Unicode’a geçmişse, karışık bir ortam oluşur: veriler eski encoding’de, UI Unicode, dışa aktarımlar Windows-1252 bekleyebilir. MariaDB burada net bir kavram (çoğunlukla utf8mb4) ve temiz bir dönüşüm ile “görünmez” hatalara karşı test planı (karşılaştırmalar, sıralama, trim/pad, özel karakterler) almalıdır.

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

Paradox/BDE çeşitli özel durumları tanır: NULL yerine boş stringler, 0‑tarihler, “boş” zaman damgaları, UI’den doğan varsayılanlar. MariaDB NULL ile boş arasında kesin ayırım yapar. Bu durum WHERE ifadelerini, agregasyonları ve hesaplamaları etkiler. Bu farklar tablo/alan bazında değerlendirilmelidir.

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

Paradox yapısında sıklıkla ara sonuçlar, dışa aktarma tamponları, kullanıcı düzenleri veya parametreler için yerel tablolar bulunur. Bazıları yerel kalmalı (ör. UI düzenleri), bazıları merkezi olmalıdır (ör. iş süreçleri, durumlar, loglar). Bir göç, bu kategorileri temizce ayırmak için bir fırsattır.

Stolpersteine bei Paradox/BDE: typische technische Unterschiede

Göçün planlanabilir olması için tekrarlayan farkları açıkça ele almak faydalıdır.

SQL-Dialekt und Operatoren

BDE/Paradox‑SQL, MySQL/MariaDB‑SQL ile birebir aynı değildir. Tarih fonksiyonları, string fonksiyonları, dış join’ler (tarihsel), Like/maske mantığı ve örtük tip dönüşümlerinde farklılıklar görülür. Kontrollü bir yaklaşım “zaten çalışıyor” yaklaşımını net kurallara çevirir: Hangi ifadeler port edilir, hangileri kasıtlı olarak yeniden yazılır, hangileri anlamlıysa view/procedure içinde kapsüllenebilir?

Sortierung und Collation

Paradox’ta sıralama düzenleri ve büyük/küçük harf duyarlılığı MariaDB’den sıkça farklıdır, özellikle umlaut’lar söz konusu olduğunda. MariaDB’de collation (örn. utf8mb4_german2_ci vs. utf8mb4_unicode_ci) karşılaştırma ve sıralamayı belirler. Bu akademik bir konu değildir: deduplikasyon, arama fonksiyonları ve unique constraint’lerin davranışını etkiler.

Autoincrement und Nummernkreise

Paradox’ta otomatik artan alanlar vardır, ancak uygulamalar sık sık özel numaralandırma mantıkları (belge numaraları, sipariş numaraları) kullanır. MariaDB’de net bir ayırım yapılmalıdır:

• Teknik birincil anahtar: ilişkiler için AUTO_INCREMENT (veya mimariye göre UUID).
• İşsel numara: işlem koruması altında ayrı bir numaralandırma, gerekirse her mükellef/dönem bazında.

İşsel bir numarayı teknik anahtar olarak kullanmaya çalışmak, ileride maliyetli yeniden çalışmalar doğurur.

Locking und Transaktionen

Dosya tabanlı erişimden gerçek bir sunucuya geçiş kazançtır, ama davranışı değiştirir. MariaDB’de işlemler (InnoDB) merkezi bir rol oynar. Transaction sınırlarının nerede olacağına karar verilmelidir: diyalog başına, her kayıt kaydında veya batch başına. Özellikle Paradox dünyasında yaygın olan uzun süreli işlemler ve dakikalar süren “edit modu” sunucu tarafında kritik olabilir (kilitler, deadlock, replikasyon gecikmesi). Bu nedenle çalışma şekli veya UI’nin uyarlanması genellikle göçün bir parçasıdır.

Vorgehensmodell: kontrollierte Migration in Etappen statt Big Bang

B2B ortamlarda işletme stabilitesi genellikle hızlı bir kesmeden daha önemlidir. Kademeli bir göç yolu riski azaltır; çünkü iş birimleri ve BT iteratif olarak doğrulayabilir.

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

İlk adımda MariaDB şeması, Paradox yapısını yansıtacak şekilde oluşturulur – ancak hedef ilkelerle: Primary Key’ler, indeksler, uygun veri tipleri, utf8mb4, InnoDB. Paralel olarak yeniden üretilebilir bir import süreci (skriptler/araçlar) oluşturulur; gerektiğinde tekrarlanabilmelidir. Burada tekrar üretilebilirlik önemlidir, çünkü göç genellikle ilk çalışmada “tamamlanmaz”.

Bu etap tipik olarak şu çıktıları üretir:

• Versiyonlanmış şema tanımı (DDL) (örn. Git)
• Alan eşleştirme listesi (Paradox → MariaDB) ve dönüşüm kuralları
• Protokollü import prosedürü (kayıt sayıları, hatalar, sapmalar)
• İlk doğrulama raporları (counts, toplamlar, checksum’lar)

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

Asıl modernizasyon adımı BDE’den ayrıştırmadır. Delphi projelerinde BDE-Ablosung mit nativer Anbindung sıklıkla tercih edilir; çünkü modern sürücüler, işlemler, parametre bağlama ve farklı SQL backend’leri için birleştirilmiş bileşenler sunar. Önemli olan “BDE gitti” değil, ardından kodun nasıl göründüğüdür: merkezi veri erişimi, net hata yönetimi, string birleştirme yerine temiz parametre kullanımı.

Bu etapta tipik görevler:

• TTable/TQuery’nin FireDAC query ve DataSet’leri ile değiştirilmesi
• İlerideki Layer-3 mimarisi için bir Data‑Access‑Layer (DAL) kurulması
• Transaction scope’larının standardize edilmesi (Commit/Rollback)
• SQL incelemesi: diyalekt uyarlaması, parametreler, paging, join’ler

Uygulamanız uzun vadede modernize edilecekse, bu adım saf veri göçünden daha önemlidir. 64‑Bit, modern Windows sürümleri ve temiz dağıtım hatları için teknik serbestlik sağlar.

Etappe 3: Parallelbetrieb und fachliche Abnahme ohne Betriebsbruch

Kritik sistemler için paralel işletim mantıklıdır: MariaDB kurulur ve döngüsel (veya artan) olarak doldurulur, altsistem çalışmaya devam eder. Bu sayede iş birimi karşılaştırmalar yapabilir, uç durumları tanımlayabilir ve yeni platformu yük altında test edebilir. Paralel işletim şu şekillerde uygulanabilir:

• Raporlama/BI hazırlığı için salt‑okunur replik
• Tanımlı alt alanlarda “Dual Write” (sadece iyi yönetiliyorsa)
• Birden çok kuru çalışmayla ve net bir cutover kontrol listesiyle stichtag‑göç

Kompleksliği gereksiz yere artırmamak önemlidir: Dual‑Write çekici görünür ama iş mantığı merkezileştirilmemişse hata üreticidir. Çoğu durumda iyi doğrulama ile tekrarlanabilir bir stichtag‑çalışma daha ekonomik sonuç verir.

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

Cutover’dan sonra MariaDB’nin avantajlarının sergilenmesi beklenir: referans bütünlüğü, performanslı indeksler, temiz yetkilendirme, izleme, yedekleme/geri‑yükleme testleri. Gerçek üretim yükleri genellikle bu aşamada ortaya çıkar: uzun süren raporlar, kötü indekslenmiş arama formları, batch güncellemeler. Kontrollü bir göç bu etabı açıkça planlar; onu plansız bir son işlem olarak bırakmaz.

Datentypen und Mapping: von Paradox nach MariaDB ohne Informationsverlust

Alan eşleştirmesi göçün kalbidir. Tipik atamalar (basitleştirilmiş):

• Alpha / Memo: VARCHAR/TEXT (utf8mb4 ile), uzunluk doğrulama ve trim kuralları
• Number: INT/BIGINT/DECIMAL değer aralığına göre; örtük ondalık kısımlar konusunda dikkat
• Date/Time: DATE/DATETIME/TIMESTAMP; “0‑tarih” veya NULL için net kurallar
• Logical: BOOLEAN veya TINYINT(1) ile net semantik
• Currency: Yuvarlama hatalarını önlemek için Float yerine DECIMAL(…,2/4)

Önemli olan sadece veri tiplerini çevirmek değil, aynı zamanda iş kurallarını da kaydetmektir: Bir alan NULL olabilir mi? Hangi varsayılanlar işsel olarak doğrudur? Hangi kombinasyonlar benzersiz olmalıdır? Bunlardan kısıtlar ve indeksler doğar. Bu kurallar Paradox/BDE sisteminde genellikle UI veya kod içinde örtük olarak vardı – MariaDB’de mümkün olduğunca açık hale getirilmelidir.

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

Birçok legacy veritabanı yıllarca referans bütünlüğü olmadan çalışır – ta ki entegre sistemler, portallar veya paralel süreçler devreye girene dek. O noktada veri kalitesi sınırlayıcı hale gelir. MariaDB’de Foreign Key’ler, Unique Constraint’ler ve (sürüm/engine’e bağlı olarak) CHECK’ler kullanılabilir; böylece veri hataları erken önlenir.

Pratik bir yaklaşım bütünlüğü kademeli olarak getirmektir:

• Önce çekirdek nesnelerde Primary Key’ler ve benzersiz indeksler (müşteriler, maddeler, belgeler)
• Ardından stabil alanlarda Foreign Key’ler
• “Tarihsel” verinin yoğun olduğu tablolarda: önce temizlik, sonra kısıtlar

Bu yol, cutover’ın eski yükler nedeniyle başarısız olma riskini düşürür ve genel durumu belirgin şekilde iyileştirir.

Performance in der Praxis: was sich mit MariaDB ändert

Paradox/BDE sistemleri sıkça “dosya hızı”na optimize edilmiştir: yerel indeksler, hızlı tablo erişimleri, çok client tarafı filtreleme. MariaDB ile yük sunucuya kayar. Bu olumlu bir değişimdir; ancak temiz SQL ve indeks stratejileri gerektirir.

Typische Performance-Fallen

• SELECT * büyük tablolardan, çünkü önce yerel olarak yeterince hızlıydı
• Client tarafı filtreleme yerine sunucu tarafı WHERE kullanmamak
• Eksik bileşik indeksler arama maskesi alanlarına (örn. mükellef + durum + tarih)
• LIKE ‚%text%‘ uygun tam metin stratejisi olmadan

Messbar verbessern statt „nach Gefühl“

Kontrollü bir göç erken ölçüm noktaları kurar: Slow Query Log, Explain analizleri, tekrar üretilebilir yük testleri. Bu özellikle önemlidir çünkü göçten sonra bir REST-Server veya bir Kundenportal gibi bileşenler planlanıyorsa yeni erişim desenleri (çok sayıda küçük istek, paging, arama uç noktaları) oluşacaktır.

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

Delphi projelerinde teknik modernizasyon veri erişimiyle sıkı ilişkidedir. BDE sadece “bir sürücü” değil, TTable, kayıt tabanlı gezinme, yerel filtreleme gibi tamamlayıcı bir erişim tarzıdır. MariaDB’ye geçiş, erişimi konsolide etmek için doğru zamandır.

Von „DataSets überall“ zu kontrolliertem Datenzugriff

Birçok uygulamada her form kendi sorgularına sahiptir. Bu mimari ve güvenlik açısından iyi ölçeklenmez. Başarılı olan dönüşüm yönleri şunlardır:

• Çekirdek nesneler için merkezi Repository/Service sınıfları
• Tek tip hata ve transaction yönetimi
• Parametreli sorgular (SQL Injection önleme, plan cache kullanımı)
• Servisler için yapılandırılabilir connection‑pool veya connection yönetimi

Bu, UI, iş mantığı ve kalıcılığı açıkça ayıran bir Layer-3 mimarisi için zemin hazırlar. Bu sadece veritabanı değişiminde değil, ileride REST-Server veya arka plan hizmetlerine doğru genişlemede de yardımcı olur.

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

Projelerde sıkça şu sorular ortaya çıkar: Hangi sürücü varyantı (MySQL/MariaDB), hangi SSL seçenekleri, hangi timezone ve tarih seçenekleri, hangi Unicode ayarları? Bunlar ayrıntı değil; çünkü doğrudan veri tutarlılığı (tarih/saat), sıralama ve işletme güvenliğini (TLS) etkiler. Kontrollü bir göç bu parametreleri belirler, dokümante eder ve gerçekçi veriyle test eder.

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

Cutover kendi başına bir projedir. İyi bir cutover planı yalnızca “ne zaman geçileceğini” değil, koruma önlemlerini de açıklar:

• Datenfreeze: Altsistemde ne zamandan itibaren veri girişi durdurulacak? Acil durum süreçleri var mı?
• Finaler Import: Gerçekte ne kadar sürecek? (Kuru çalıştırmalar veri verir.)
• Validierung: Hangi kontroller onay için yeşil olmalı (counts, toplamlar, örneklemeler, işsel raporlar)?
• Rollback: Ne zaman vazgeçilecek ve sonra süreç nasıl ilerleyecek?
• Kommunikation: Kim onay veriyor? War Room’da kim ulaşılabilir?

Orta ölçekli işletmelerde rollback genellikle teknik değil, organizasyonel olarak kritiktir. Bu yüzden göç, cutover’ın bir deney değil, prova edilmiş bir işlem olacağı şekilde hazırlanmalıdır.

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

MariaDB stabil çalışmaya başladığında ve BDE‑kaldırma düzgün gerçekleştirildiğinde yeni seçenekler ortaya çıkar: dış sistemler için REST‑API’leri, arka plan işlemleri olarak Windows veya Linux‑servisleri, UI ile iş mantığının ayrılması ve perspektif olarak çok platformlu istemciler. Sıkça bir sonraki adım, masaüstündeki iş mantığını çekip entegrasyonları (ERP/DMS/CRM) ve portalları kontrollü biçimde sunan servisler haline getirmektir.

Önemli olan: Bir REST‑Server “ek bir katman” değil, mimari bir karardır. Veri erişimini, validasyonları ve yetkilendirmeyi zaten servisler/repository’ler içinde konsolide etmiş olanlar, sağlam API’ler geliştirmeyi çok daha kolay bulacaktır.

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

• Hangi modüller iş açısından kritik ve cutover gününde kesinlikle çalışıyor olmalı?
• Gerçek veri hacimleri nasıl (tablo boyutları, büyüme, arşivleme)?
• Hangi raporların birebir aynı olması gerekiyor, hangileri iyileştirilebilir?
• Hangi entegrasyonlar sisteme bağlı (dışa aktarımlar, ODBC, Office, baskı hattı)?
• Mükellef/tenant özelliği var mı, varsa bugün nasıl modellenmiş?
• Hangi işletme gereksinimleri geçerli (yedek penceresi, geri yükleme süresi, haklar, denetim)?

Bu açıklamalar bürokrasi değil; bir göçun “teknik olarak tamam” olmasına rağmen işsel onay alamamasını engeller.

Fazit: Kontrolliert migrieren heißt Risiken planbar machen

Paradox ve BDE’nin MariaDB’ye kontrollü göçü, uygulamayı bir bütün sistem olarak modernize etmek demektir: veri modeli, SQL, işlemler, karakter setleri, erişim katmanı ve işletme süreçleri. Geçişi salt bir dışa aktarım olarak görenler genellikle çözmek istedikleri problemleri sadece yeni bir sunucuya taşırlar.

Kademeli bir yaklaşım; yeniden üretilebilir import, temiz alan eşlemesi, erken doğrulama ve net bir BDE‑Ablösung (ör. FireDAC) ile çok kullanıcılı işletim, entegrasyonlar, servisler ve Delphi modernizasyonunun sonraki adımları için sağlam bir temel oluşturur.

Eğer göçünüzü işsel olarak güvenli planlamak ve işletme kesintisi olmadan uygulamak istiyorsanız, başlangıç durumunu, riskleri ve gerçekçi bir etappenplanı memnuniyetle beraber tartışırız: https://net-base-software-gmbh.de/kontakt/