データベースの専門家になるための探求記

データベースエンジニアの見習いとして現場に入り、先輩方の設計やトラブル対応を間近で見ていると、**「最初の設計の良し悪しが、数年後の開発効率やシステム移行（モダナイズ）の成否を決定づける」**ということを痛感します。 今回は、私が実務と学習を通じて学んだ、将来の自分（とチーム）を助けるための設計のコツを整理してまとめます。 1. NULLは「なるべく避ける」が鉄則 設計の初期段階で最も意識しているのが、「安易にNULLを許可しない」ことです。 プログラムを複雑にしない : アプリ側で値を取り出す際、常に「もしNULLだったら」というチェックが必要になり、バグの温床になります。 集計ミスを防ぐ : SQLの集計関数（ COUNT や AVG など）ではNULLが無視されるため、直感に反する計算結果を生むことがあります。 【現場での学び】 可能な限り NOT NULL 制約をつけ、未入力が想定される場合は「デフォルト値」を設定する。制約によってデータの品質をDBの入り口で担保する重要性を実感しています。 2. データベースの「制約」を最大限に活用する データの正しさを守るのはプログラムだけではありません。DB自体が持つガード機能を信頼することが大切です。 主キー（Primary Key） : データの重複を物理的に許さない。 一意制約（Unique） : 重複を避けるべき項目（メールアドレスなど）を守る。 チェック制約（Check） : 「0以上の数値しか認めない」など、値の妥当性をDBレベルで保証する。 アプリ側だけでなく、DB側で「守りの設計」を固めることで、直接データを操作した際のリスクも最小限に抑えられます。 3. 「有意コード」の誘惑に負けない 「商品コードの先頭2桁がカテゴリを表す」といった、値自体に意味を持たせた「有意コード」は、一見便利ですが避けるべきだと学びました。 仕様変更に弱い : カテゴリ体系が変わった瞬間、全てのコードを書き換える地獄が発生します。 無意コード（サロゲートキー）の推奨 : 意味を持たない連番などを主キーにし、属性（カテゴリなど）は別カラムで管理するほうが、将来の拡張やモダナイズに強い設計になります。 4. 「物理削除」ではなく「論理削除」を検討する データを消す際、 DELETE で消し去る（物理削除）のか、フラグで非表示に...

  システムを構築する際、データベースサーバー本体を立てるだけでなく、「別のアプリケーションサーバーからDBに接続する」という構成はバックエンド開発において日常茶飯事です。 現在取り組んでいるモダナイズ（近代化）の学習でも、新旧サーバー間での接続確認が欠かせません。今回は、CentOS 9環境にOracle Instant Clientを導入し、リモートのOracle 11gへ接続するための実験記録をまとめます。 1. 接続環境の準備：Instant Clientのダウンロード まずは接続元となるCentOS 9に、軽量なクライアントパッケージである「Instant Client」を導入します。 接続先のバージョンに合わせ、以下の2つのRPMファイルを公式サイトから入手しました。 Basicパッケージ : 接続に最低限必要なライブラリ群 SQL*Plusパッケージ : コマンドラインからSQLを実行するためのツール ダウンロード元： Oracle Instant Client for Linux x86-64   2. 依存ライブラリのインストール CentOS 9（Stream 9など）の標準状態では、Oracleクライアントが動作するために必要な古いライブラリが不足していることがあります。これがないと実行時にエラーが出るため、あらかじめ導入しておきます。 Bash sudo dnf install -y libaio libnsl 3. クライアントのインストール ダウンロードしたRPMファイルを、 sudo を使ってインストールします。 Bash sudo rpm -ivh ./oracle-instantclient11.2-basic-11.2.0.4.0-1.x86_64.rpm sudo rpm -ivh ./oracle-instantclient11.2-sqlplus-11.2.0.4.0-1.x86_64.rpm インストール先を確認すると、以下のディレクトリに配置されていました。 /usr/lib/oracle/11.2/client64 4. 環境変数の設定（ここが重要！） インストールしただけでは sqlplus コマンドは使えません。OSにライブラリの位置を教えるための設定が必要です。 私は .bash_profil...

 日本のエンタープライズ領域において、サーバーOSとして圧倒的なシェアを誇るのが Red Hat Enterprise Linux (RHEL) です。 将来、データベースの専門家として現場で活躍するためには、RHEL環境でのOracle構築スキルは避けて通れません。今回は、あえて旧バージョンである「Oracle Database 11g Express Edition (XE)」をRHELに導入した記録をまとめます。 1. なぜ今、あえてOracle 11gをRHELで学習するのか？ 現在、多くの日本企業では、長年稼働し続けて保守期限が切れた Oracle 11g が、システムの「塩漬け」状態で残っています。 これらのレガシーシステムを最新環境へ移行（モダナイズ）するためには、まず現状の11gがどのような仕様で動いているのかを正確に把握しなければなりません。本番環境を想定した再現と、将来のPostgreSQL等への移行シミュレーションを見据え、今回は Oracle 11gの学習のために この環境を構築します。 ※注意点 今回使用する「Express Edition (XE)」は、あくまで学習・開発用のエディションです。 本番環境での利用は想定されておらず、商用ライセンス版とは制限事項が異なる 点に十分注意してください。 2. 事前チェック：Swap領域の確保 Oracle Databaseは、物理メモリが十分であっても、一定の**Swap領域（仮想メモリ）**が割り当てられていることをインストールの前提条件としています。RHELでの環境構築において、ここで躓くケースが非常に多いため、必ず最初に確認しましょう。 (1) 現在のSwap領域を確認する方法 まず、現在のシステムでSwapがどの程度割り当てられているかを確認します。 Bash # メモリとSwapの使用状況を表示 free -m ここで Swap の total が 2048MB（2GB）以上あれば、Oracle XEの導入には十分です。もし「0」であったり、数百MBしかない場合は、以下の手順で増設が必要です。 (2) Swap領域が不足する場合の増加方法 パーティションを切り直すのはリスクがありますが、RHELでは「スワップファイル」を作成することで、動的に領域を増やすことが可能で...