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

 データベースの学習を進める上で、世界中で広く使われている 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 で消し去る（物理削除）のか、フラグで非表示に...