Paradox と BDE を制御された形で MariaDB に移行する

多くの Delphi 製の業務アプリケーションは、当時の実用的な標準であったため、Paradox テーブルと Borland Database Engine (BDE) を用いて作られました。ローカルで即稼働でき、インフラが少なく済むという理由です。実務ではこれらのシステムが今日まで稼働していることが多く、レポーティング、ラベル印刷、インポート/エクスポート、バッチ処理、履歴テーブル、長年にわたりデータアクセスに「入り込んだ」特殊なロジックなどを含んでいます。だからこそ、マイグレーションは単なるデータのエクスポートではなく、制御された再設計です：データモデル、SQL の挙動、コード内の副作用、運用プロセスを合わせて検討する必要があります。

MariaDB は、堅牢な複数ユーザー運用、整ったトランザクション、中央バックアップ、レプリケーション、明確な権限管理、Web ポータルやサービス、あるいは REST-API との接続可能性を求める場合、しばしば適切なターゲットプラットフォームになります。ここでの課題はたいていデータベースのインストールそのものではなく、安全なマイグレーション経路にあります：テーブル、インデックス、プライマリキー、文字セット、日付フィールド、「空」の値、参照関係を、業務ロジックを稼働中に壊すことなく正しく移行するにはどうするか、という点です。

本稿は、Paradox と BDE を MariaDB へ制御された形で移行するための実践的な手順を示します：技術的に根拠があり、段階的で、安定性にフォーカスしたアプローチです。目的は、さらに進めるための堅実な基盤を作ることです — 例えば BDE の置換、ネイティブ接続による BDE の置換、明確な Layer-3 アーキテクチャ、REST サーバ、およびプラットフォーム対応クライアントなどです。

なぜ Paradox/BDE の移行は単なるデータベース切替以上なのか

Paradox というファイル形式と BDE というアクセス層は、MariaDB に対して 1:1 で「再現」すべき固有の挙動を伴う一体のシステムです。現場でよく見られる典型的な症状は次のとおりです：

• 不透明な依存関係：SQL ステートメントが各所に分散（フォーム、DataModules、レポート、動的な文字列 SQL）しており、中央での管理がないことが多い。
• “感覚的”な振る舞い：特定のフィルタやソート、結合がたまたま動作するのは、Paradox/BDE が寛容であったり暗黙の型変換を行っているからである場合がある。
• 複数ユーザー時の限界：ファイルベースのロック、ネットワーク上でのパフォーマンス低下、データ量増加に伴うロッキング問題。
• 保守リスク：BDE 依存、古いドライバ、最新の Windows バージョンでのデプロイ困難、64 ビット/ARM64 の問題など。

制御されたマイグレーションは、これらを副次的な問題として扱うのではなく、目標基準として扱います。MariaDB は単なる「新しいデータベース」ではなく、データアクセス層を切り離し、業務上の整合性を高め、インターフェース性を確立する機会でもあります。

目指す姿：デスクトップ、サービス、ポータルのための安定した MariaDB 基盤

B2B 業務アプリケーションにとって実用的な目標像は、通常次の三層から成ります：

• データベース (MariaDB)：一貫したデータ保管、インデックス、制約、トランザクション、ユーザー/ロール、バックアップ。
• 業務ロジック (サーバ/サービス)：バリデーション、ワークフロー、インポーター、スケジューラ、インターフェース。オプションとして REST-サーバ、Windows または Linux-サービス として。
• クライアント (VCL/FMX/Web)：操作画面、レポート、オフライン部分、連携。可能ならば業務ロジックとの明確な契約を持つこと。

出発点によっては、すべてを即時実装する必要はありません。しかし、マイグレーションは将来のクリーンなアーキテクチャへの道を塞がないよう設計されるべきです。今日ただテーブルをコピーして、明日また各フォームから直接データベースへ書き込むようでは、MariaDB を導入しただけで本質的なリスクは残ります。

現状把握：実際に何を移行すべきか

最初に行うのは「テーブル数はいくつか」を超えた棚卸しです。Paradox/BDE プロジェクトでは、データベースは全体の一部であることが典型的です。重要な観点は次の通りです：

1) テーブル、インデックス、いわゆる擬似キー

真の Primary Key が欠けていることが多い。代わりにフィールドの組合せ、明確な制約のない連番、アプリケーションで管理される「Key」フィールドが存在します。MariaDB ではこれらを堅牢な一意キーにする必要があります — そうでなければトランザクションや参照整合性は限定的にしか機能しません。

2) クエリ、動的 SQL ブロック、レポート

BDE はコンポーネントにより異なる SQL 方言を使い、「創意工夫」されたステートメントを許容することがあります。レポーティングコンポーネント（古いものも含む）は独自の SQL 定義を持つことが多いです。マイグレーションはこれらのソースを発見し、分類する必要があります：重要なコアクエリ、稀に使われる集計、特殊なインポートなど。

3) 文字セットと特殊文字（ウムラウト、ISO/ANSI、Unicode）

多くの Paradox アプリケーションは歴史的に ANSI ベースです。Delphi アプリケーション自体が途中で Unicode に切り替わっている場合、エンコーディングが混在することがあります：データは古いエンコーディング、UI は Unicode、エクスポートは Windows-1252 を期待する、など。MariaDB にはここで明確な方針（典型的には utf8mb4）が必要です。変換と「目に見えない」エラー（比較、ソート、Trim/Pad、特殊文字）に対するテストも含めるべきです。

4) 「空」値、NULL ロジック、日付フィールド

Paradox/BDE には様々な特殊ケースがあります：NULL の代わりに空文字列、0 値のデータ、「空」のタイムスタンプ、UI で生まれるデフォルト値など。MariaDB は NULL と空文字列を厳密に区別します。これは WHERE 句、集計、計算に影響します。これらの違いはテーブル／フィールドごとに評価する必要があります。

5) 周辺アーティファクト：セッションテーブル、ローカル設定、キャッシュ

Paradox 構造には、途中結果用のローカルテーブル、エクスポートバッファ、ユーザーレイアウトやパラメータが置かれていることが多い。UI レイアウトなどは引き続きローカルが適切なこともあれば、作業プロセスやステータス、ログは中央に置くべき場合もあります。マイグレーションはこれらのカテゴリーを整理する機会です。

Paradox/BDE の落とし穴：典型的な技術差異

マイグレーションを計画可能にするため、繰り返し現れる差異を明示的に扱う価値があります。

SQL 方言と演算子

BDE/Paradox の SQL は MySQL/MariaDB の SQL と同一ではありません。日付関数、文字列関数、外部結合（歴史的な実装）、Like/マスクロジック、暗黙の型変換などで差が出ます。管理されたアプローチでは「とりあえず動く」をやめ、明確なルールを定めます：どのステートメントを移植するか、どれを意図的に書き直すか、どれをビューやストアドプロシージャで包むか（適切なら）。

ソート順と照合順序（Collation）

Paradox ではソート順や大文字小文字の扱いが MariaDB としばしば異なります。特にウムラウトで顕著です。MariaDB では Collation（例: utf8mb4_german2_ci と utf8mb4_unicode_ci）により比較とソートが決まります。これは単なる理論ではなく、重複除去、検索機能、ユニーク制約の挙動に直接影響します。

オートインクリメントと番号管理

Paradox にも自動採番フィールドはありますが、アプリケーションはしばしば独自の番号体系（伝票番号、注文番号）を特殊なロジックで運用しています。MariaDB では明確に分離するべきです：

• 技術的プライマリキー：関係性のための AUTO_INCREMENT（またはアーキテクチャ次第で UUID）。
• 業務上の番号：トランザクション保護された独自の番号体系（必要に応じてテナントや期間単位）。

業務番号を技術的キーとして流用すると、後で高額な改修を招くことになります。

ロッキングとトランザクション

ファイルベースから真のサーバへ移行することは利点ですが、挙動が変わります。MariaDB では InnoDB を用いたトランザクションが中心です。トランザクションの境界をどこに置くか（ダイアログ単位、保存操作単位、バッチ単位）は設計上の重要判断です。特に Paradox 系では数分に及ぶ「編集モード」のような長いトランザクションが一般的であり、サーバ側ではロックやデッドロック、レプリケーション遅延の観点から問題になります。ここでは作業手順や UI の調整がマイグレーションの一部となることが多いです。

進め方：Big Bang ではなく段階的で制御された移行

B2B 環境では運用の安定性が迅速な切替より優先されることが多いです。段階的な移行はリスクを低減し、業務部門と IT が反復的に検証できる利点があります。

段階 1：コード改修なしのデータモデル移行とマッピング

最初の段階では、Paradox 構造を反映する MariaDB スキーマを作成しますが、同時に目標原則を取り入れます：Primary Keys、インデックス、適切なデータ型、utf8mb4、InnoDB。並行して再現可能なインポートプロセス（スクリプト/ツール）を作成し、必要に応じて繰り返し実行できるようにします。マイグレーションは初回で完了することは稀であり、再現性が重要です。

この段階の成果物例：

• バージョン管理されたスキーマ定義（DDL）（例: Git）
• フィールドマッピング表（Paradox → MariaDB）および変換ルール
• インポート手順とログ出力（件数、エラー、外れ値）
• 初期の検証レポート（件数、合計、チェックサム）

段階 2：データアクセスからの BDE 置換（例：FireDAC を用いて）

実際の近代化で重要なのは BDE からの切り離しです。Delphi プロジェクトでは、BDE-Ablosung mit nativer Anbindung が信頼できる手段とされます。なぜならそれがモダンなドライバ、トランザクション、パラメータバインディング、異なる SQL バックエンド向けの統一コンポーネントを提供するからです。重要なのは「BDE を除くこと」ではなく、除いた後のコードがどうあるかです：中央化されたデータアクセス、明確なエラー処理、文字列連結によらないきれいなパラメータ利用。

この段階での典型的な作業：

• TTable/TQuery の置換を FireDAC ベースの Query や DataSet に置き換える
• 後続の Layer-3 アーキテクチャの基盤となる Data-Access レイヤ（DAL）の導入
• トランザクションスコープの標準化（Commit/Rollback）
• SQL レビュー：方言適合、パラメータ化、ページング、結合の見直し

アプリケーションを長期的にモダナイズする予定がある場合、このステップは単なるデータ移行以上に重要になることが多いです。64 ビット化、モダンな Windows バージョン、整ったデプロイメントパイプラインへの自由度を生みます。

段階 3：並行稼働と業務部門による受け入れ（運用停止なしで）

重要なシステムでは並行稼働が有効です：MariaDB を構築して周期的またはインクリメンタルにデータを投入し、既存システムは継続稼働させます。これにより業務部門は出力を比較し、エッジケースを特定し、新プラットフォームを負荷下でテストできます。並行稼働にはいくつかの実装方法があります：

• レポーティング/BI 準備のためのリードオンリー複製
• 定義された領域での「デュアルライト」（ただし高度な制御ができる場合のみ）
• 複数回のドライランと明確なカットオーバーチェックリストを伴う日付指定移行

重要なのは複雑さを増やしすぎないことです：デュアルライトは魅力的に聞こえますが、業務ロジックが中央化されていない場合は障害が発生しやすい。多くの場合、再現可能な日付指定移行と十分な検証を行う方が経済的です。

段階 4：最適化、整合性、パフォーマンス、運用プロセス

カットオーバー後は、MariaDB の強みを活かす段階です：参照整合性、効果的なインデックス、適切な権限設定、監視、バックアップ/リストアの検証。ここで初めて「実際の」本番負荷が明確になることが多い：長時間のレポート、インデックス不足の検索、バッチ更新など。制御された移行はこの段階を予め計画に含め、後付けの手戻りを減らします。

データ型とマッピング：情報損失なく Paradox から MariaDB へ

フィールドマッピングはマイグレーションの核です。典型的な対応（簡略化）は次のとおりです：

• Alpha / Memo：VARCHAR/TEXT（utf8mb4）、長さチェックと Trim 規則
• Number：範囲に応じて INT/BIGINT/DECIMAL；暗黙の小数扱いに注意
• Date/Time：DATE/DATETIME/TIMESTAMP；“0 日付” と NULL の取り扱いルール
• Logical：BOOLEAN または TINYINT(1) として明確な意味づけ
• Currency：丸め誤差を避けるため FLOAT ではなく DECIMAL(…,2/4)

重要なのはデータ型だけを写すのではなく、業務ルールも文書化することです：フィールドは NULL を許すか、どのデフォルトが業務的に正しいか、どの組合せが一意であるべきか。これらから制約とインデックスが導かれます。Paradox/BDE システムではこれらのルールが UI やコードに暗黙的に埋め込まれていることが多いため、MariaDB では可能な限り明示化するべきです。

整合性：Primary Keys、Foreign Keys、ユニークインデックスの導入

多くのレガシーデータベースは長年にわたり参照整合性なしで機能しますが、統合、ポータル、並列プロセスが加わるとデータ品質が制約になります。その時点で MariaDB 上で Foreign Key、Unique Constraint、Checks（バージョンやエンジンに依存）を使うことにより、データ不整合を早期に防げます。

実行可能な手順としては段階的に整合性を導入します：

• まずはコアオブジェクト（顧客、商品、伝票）に Primary Key と一意インデックスを設ける
• 次に安定した領域から Foreign Key を追加する
• 「履歴」テーブルのようにデータにゴミが多い場合は、まずはクレンジングを行い、その後に制約を追加する

これによりカットオーバーが旧データの負債によって失敗するリスクを低減し、全体の状況を大きく改善できます。

実務でのパフォーマンス：MariaDB で変わること

Paradox/BDE システムは「ファイルの速さ」を前提に最適化されていることが多く、ローカルインデックス、迅速なテーブルアクセス、クライアント側での大量フィルタリングが行われます。MariaDB では処理がサーバ側に移るため、綺麗な SQL とインデックス戦略が求められます。

典型的なパフォーマンスの落とし穴

• SELECT * を大きなテーブルから取得する（以前はローカルで十分に速かったため）
• クライアント側フィルタリング を行い、サーバ側 WHERE を使わない
• 検索用フィールドに対する複合インデックスの欠如（例：テナント + ステータス + 日付）
• 適切な全文検索戦略のない LIKE ‚%text%‘

感覚ではなく計測で改善する

制御された移行では早期に測定ポイントを定めます：Slow Query Log、Explain の解析、再現可能な負荷テスト。これは特に、移行後に REST サーバや 顧客ポータル のような追加コンポーネントを予定している場合に重要です。これらは新しいアクセスパターン（多数の小さなリクエスト、ページング、検索エンドポイント）を生むためです。

Delphi 特有の点：BDE 置換、FireDAC と整ったアクセス層

Delphi プロジェクトでは技術的な近代化はデータアクセスと密接に結びついています。BDE は単なるドライバではなく、TTable、レコードベースのナビゲーション、ローカルフィルタといった一貫したアクセススタイルを提供してきました。MariaDB への移行はアクセスの統合を進める好機です。

“あちこちに DataSet” から制御されたデータアクセスへ

多くのアプリケーションは各フォームごとにクエリを持ち、これがスケーラビリティとセキュリティの面で問題になります。効果的なのは次のような方針への移行です：

• コアオブジェクトのための集中したリポジトリ/サービスクラス
• 統一されたエラー及びトランザクション処理
• パラメータ化されたクエリ（SQL Injection の回避、プランキャッシュの活用）
• サービス向けの接続プールや接続管理の設定

こうして UI、業務ロジック、永続化を分離する Layer-3 アーキテクチャの基盤ができます。これはデータベース切替時だけでなく、後の REST サーバやバックグラウンドサービスへの拡張にも寄与します。

FireDAC による MariaDB 接続：典型的に決めるべき事項

プロジェクトでは常に同じ疑問が出ます：どのドライバ（MySQL/MariaDB）を使うか、どの SSL オプション、タイムゾーンと日付オプション、Unicode 設定はどうするか？これらは単なる細部ではなく、データ整合性（日付/時刻）、ソート、運用安全性（TLS）に直接影響します。制御されたマイグレーションではこれらのパラメータを決め、文書化し、実データでテストします。

カットオーバープラン：移行日、データフリーズ、ロールバック — 想定外をなくす

カットオーバーはそれ自体で一つのプロジェクトです。良いカットオーバープランは「いつ切り替えるか」だけでなく保護策も記述します：

• データフリーズ：旧システムでいつ以降データ入力を止めるか？緊急時の手順はあるか？
• 最終インポート：現実的にどれくらい時間がかかるか？（ドライランで把握する）
• 検証：開放前にどのチェックを満たす必要があるか（件数、合計、サンプリング、業務的なレポート）
• ロールバック：いつ中止するか、その後の手順は？
• コミュニケーション：誰が承認するか？ウォールームに誰が常駐するか？

中堅企業ではロールバックは技術的というより組織的に重大であることが多いです。したがって、カットオーバーは実験ではなく、準備済みの手順である必要があります。

移行後：REST、サービス、マルチプラットフォームの基盤

MariaDB が安定稼働し、BDE の置換が適切に行われると、新たな選択肢が生まれます：外部システム向けの REST API、バックグラウンド処理を Windows や Linux のサービスとして実装、UI と業務ロジックの分離、将来的なマルチプラットフォームクライアントへの展開など。特に頻繁に見られる次の一歩は、デスクトップ内部にある業務ロジックを抜き出し、ERP/DMS/CRM やポータルとの統合を制御しながら提供することです。

ここで重要なのは：REST サーバは「追加の層」ではなくアーキテクチャの決定です。データアクセス、バリデーション、権限をすでにサービスやリポジトリで統合している場合、堅牢な API の開発は遥かに容易になります。

実務チェックリスト：プロジェクト開始前に確認すべきこと

• どのモジュールが業務上重要で、カットオーバー当日に確実に稼働させる必要があるか？
• 実データ量はどの程度か（テーブルサイズ、成長率、アーカイブ方針）？
• どのレポートを 1:1 で維持する必要があり、どれを改善して良いか？
• どの連携がシステムに依存しているか（ファイルエクスポート、ODBC、Office、印刷フロー）？
• マルチテナント対応はあるか、ある場合は現在どのように表現されているか？
• 運用要件は何か（バックアップウィンドウ、復旧時間、権限、監査）？

これらの確認は単なる書類仕事ではなく、マイグレーションが「技術的には完了」しても業務的に受け入れられない事態を避けるために必要です。

結論：制御された移行はリスクを計画可能にする

Paradox と BDE を MariaDB へ制御して移行するとは、アプリケーションをシステム全体として近代化することを意味します：データモデル、SQL、トランザクション、文字セット、アクセス層、運用プロセス。移行を単なるエクスポートと考えると、期待していた問題を新サーバ上にそのまま持ち込むことになりがちです。

一方で、再現可能なインポート、明確なフィールドマッピング、早期の検証、そして BDE の明確な置換（例：FireDAC を使った）を含む段階的なアプローチは、複数ユーザー運用、統合、サービス化、さらに Delphi の近代化の次のステップへの堅牢な基盤を築きます。

移行を業務面で安全に計画し、運用停止なく実行したい場合は、出発点の整理、リスクの評価、現実的な段階計画についてご相談ください： https://net-base-software-gmbh.de/kontakt/