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

なぜH2なのか？ 今回は、軽量でインストール不要なH2 Databaseを使って、SQLの基礎をローカル環境で試行錯誤できるようにしました。 H2 Databaseは、本番ではあまり利用されませんが、その軽量性から、開発での利用をよく見かけます。 ステップ1：ファイルのダウンロードと配置 ・公式サイトへアクセス: H2 Database Engine を開きます。 ・ZIPをダウンロード: 「Download」セクションにある 「Platform-Independent Zip」 をクリックしてダウンロードします。 ・解凍と配置: ダウンロードした h2-xxxx-xx-xx.zip をダブルクリックして解凍します。 ステップ2：実行権限の付与（初回のみ） ・Macのセキュリティ設定により、そのままでは実行できない場合があるため、ターミナルで権限を与えます。 ・ターミナルを開きます。 ・cd コマンドで、解凍した h2/bin フォルダまで移動します。 ・以下のコマンドを実行して、実行用ファイルに権限を付与します。 chmod +x h2.sh ステップ3：H2データベースの起動 同じフォルダ（h2/bin）で以下のコマンドを打ちます。 ./h2.sh 自動的にブラウザが開けば成功です。 ※ブラウザが開かない場合: ターミナルに表示されている http://192.168...:8082 のようなURLをコピーしてブラウザに貼り付けてください。 ステップ4：ログインとSELECT確認 ブラウザのログイン画面で、以下の情報を入力して「Connect」を押しました。 JDBC URL: jdbc:h2:~/test User Name: sa Password: （空欄） 接続後、以下のSQLを1行ずつ（またはまとめて）実行しました。 SQL -- テーブル作成 CREATE TABLE USERS (ID INT PRIMARY KEY, NAME VARCHAR(255)); -- データ挿入 INSERT INTO USERS VALUES (1, 'Taro'); -- 確認（SELECT） SELECT * FROM USERS; エラーなく実行できました。 test.mv.dbがホームディレクトリにできていました。 ここに上のSQLの結果（...

プロのデータベースエンジニアを目指す上で、実行計画（Execution Plan）を正確に読み解く力は必須スキルです。SQLが「なぜ遅いのか」を推測ではなく、確信を持って指摘できるようになることが本シリーズの目標です。 第1回は、100万件規模のデータを用いて、PostgreSQL 16における「全件スキャン」の実行計画を読み解くための実験環境を構築します。 0. 動作環境 本記事では、エンタープライズ環境で標準的なOracle Linux 9を使用します。 $ cat /etc/os-release NAME="Oracle Linux Server" VERSION="9.7" 1. PostgreSQL 16 のインストール OS標準のリポジトリではなく、PostgreSQL公式のPGDGリポジトリから最新のv16を導入します。 # ① 公式リポジトリの追加 sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm # ② OS標準モジュールの無効化とインストール sudo dnf -qy module disable postgresql sudo dnf install -y postgresql16-server # ③ データベースの初期化 sudo /usr/pgsql-16/bin/postgresql-16-setup initdb # ④ サービスの起動と自動起動設定 sudo systemctl enable --now postgresql-16 2. ログイン認証の仕組みと設定 PostgreSQLのデフォルトは「ピア認証」です。作業をスムーズにするため、自分のOSユーザーと同じ名前のDBユーザーを作成しておきます。 # OSユーザーと同じ名前のDBユーザーとDBを作成 sudo -u postgres createuser --superuser $(whoami) sudo -u postgres createdb $(whoami) # 以降は「psql」だけで接続...

 データベースの学習を進める上で、世界中で広く使われている MySQL を避けては通れません。今回は、手元のMacにMySQLをインストールし、いつでもSQLの練習や検証ができる「マイ・ラボ」を構築した記録をまとめます。 1. インストーラーの入手 まずは公式サイトのアーカイブから、自分のMacのOSバージョンに合ったインストーラーをダウンロードします。 入手先： MySQL Community Server (Archives) 最新版も良いですが、実務での普及率や安定性を考えてバージョンを選ぶのも、エンジニアらしい「こだわり」の第一歩です。 2. インストール作業 ダウンロードした .dmg ファイルを開き、インストーラーの指示に従って進めます。 途中で Rootパスワード の設定を求められます。これはデータベースの全権限を持つ重要なパスワードなので、忘れないようにしっかり管理します。インストールが完了すると、Macの「システム設定（システム環境設定）」の一番下に MySQL のアイコンが出現します。 ここから、ボタン一つでMySQLの「起動」と「停止」が切り替えられるようになります。 3. ターミナルから操作するための設定（PATHを通す） インストールしただけでは、ターミナルで mysql と打っても「コマンドが見つかりません」と言われてしまいます。どこからでもMySQLを呼び出せるように PATH（パス） を通します。 使用しているシェル（zshなど）の構成ファイル（ ~/.zshrc など）に、以下のパスを追記します。 Bash # MySQLの実行ファイルがある場所を指定 export PATH= $PATH :/usr/ local /mysql/bin 設定を反映（ source ~/.zshrc ）させれば、準備完了です！ 4. ログイン確認：いざ、データベースの世界へ ターミナルを立ち上げ、以下のコマンドでログインを試みます。 Bash mysql -u root -p 設定したパスワードを入力し、 mysql> というプロンプトが表示されれば成功です！ 5. まとめとこれからの学習 MacにMySQLが入ったことで、いつでも気軽にテーブル設計の練習や、複雑なクエリの実験ができるようになりました。

 これまではMacやRHEL（Red Hat Enterprise Linux）系でデータベースを触ってきましたが、今回はUbuntu 22.04 LTS環境を使ってPostgreSQL 16を導入しました。 実際に触ってみて感じたのは、**「Ubuntuはコマンド体系やファイル管理が非常にシンプルで扱いやすい」**ということです。今回はその導入手順と、実務で役立つ「複数クラスタの同時起動」の実験記録をまとめます。 1. なぜUbuntuを選んだのか？ 実務では堅牢なRHEL系が選ばれることも多いですが、学習用としてUbuntuを使ってみて、その「シンプルさ」に驚きました。 パッケージ管理が直感的 : apt コマンドの依存関係解決がスムーズ。 設定ファイルの配置が明快 : /etc/postgresql/16/main/ のように、バージョンごとに整理された構造が分かりやすい。 情報の豊富さ : 世界中のエンジニアが使っているため、困った時の解決策がすぐに見つかる。 こうした「管理のしやすさ」は、試行錯誤を繰り返す学習フェーズでは大きなメリットだと感じています。 2. PostgreSQL 16のインストール手順 Ubuntu標準のリポジトリではなく、最新のマイナーバージョンを確実に追えるよう公式リポジトリを利用します。 (1) リポジトリの作成と鍵の登録 Bash # 公式リポジトリの追加 sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list' # 署名鍵の登録 wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - # リストの更新 sudo apt-get update (2) インストール Bash sudo apt -y install postgresql-16 インストール後、管理用のOSユーザー postgres にパスワードを設定しておきました。 sudo passw...

データベースエンジニアの見習いとして現場に入り、先輩方の設計やトラブル対応を間近で見ていると、**「最初の設計の良し悪しが、数年後の開発効率やシステム移行（モダナイズ）の成否を決定づける」**ということを痛感します。 今回は、私が実務と学習を通じて学んだ、将来の自分（とチーム）を助けるための設計のコツを整理してまとめます。 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...