花火をしながらビールを飲みたい！ クラウドソリューション開発部の北島です。
皆さんは、「初めてテーブル定義書のレビューを任されたけど、何をチェックすればいいかわからない」-このような経験はありませんか？
本記事では、「テーブル構成」 に焦点を当て、レビュー時に確認すべきポイントを紹介します。
1. はじめに
現在かかわっているプロジェクトで、他チームからテーブル定義のレビューを行ってほしいという話をいただいたのが事の始まりでした。テーブルレビューの経験がなかった私は、まず基本的な知識を身に付けたうえで、レビュー時の観点を整理することにしました。
レビューを通じて、データベース設計では 「テーブル構成」と「正規化」の2つが重要な観点であることに気づきました。今回はそのうちの「テーブル構成」 に絞って、レビューを通して得た学びを紹介します。
いつか正規化についても記事を書けたらと思います。
2. テーブル構成の3つのチェックポイント
その１：テーブルの役割を明確化するべし
さて、何事も基本に立ちかえるのが大事ということで、「テーブル」とは何かから確認しましょう。
テーブルとは、「テーブル名と共通したレコードの集合体」です。
たとえば「社員テーブル」なら、そこには社員ひとりひとり（＝レコード）がずらりと並んでいて、名前や部署、入社日などの情報がまとまっています。つまり、”社員”というテーマで共通するデータがひとつのテーブルに収まっているというわけです。
ここから、テーブルの 「役割」が明確であることが基本構造の肝であるということがわかります。
では逆に、「役割」が曖昧なテーブルとはどのような構造でしょうか。 たとえば、次のような「ユーザーテーブル」があったとします。
|
1 2 3 4 5 6 7 8 9 10 11 |
CREATE TABLE user ( id INT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100), password_hash VARCHAR(255), last_login_at DATETIME, shipping_address TEXT, marketing_opt_in BOOLEAN, payment_info TEXT ); |
一見、「ユーザー情報をまとめたテーブル」に見えますが、よく見るとさまざまな情報が詰め込まれています。
- ログインに関する情報（
password_hash,last_login_at） - 配送に関する情報（
shipping_address） - マーケティングの設定（
marketing_opt_in） - 決済関連の情報（
payment_info）
これらはそれぞれ異なる役割のデータであり、本来は別々のテーブルで管理すべきものです。
テーブルの役割がぼやけると、以下のような問題が発生します：
- 拡張しづらい：新しい配送先を追加したい場合、ユーザーテーブルを変更する必要がある
- 保守が困難：決済情報の変更が、ユーザー情報全体に影響する可能性がある
- データの不整合：マーケティング設定の更新時に、関係のない情報まで触ってしまうリスク
このような問題を避けるためにも、「このテーブルは何を表すのか？」「1レコード＝何の単位なのか？」を常に意識して構成をチェックすることが重要であると学ぶことができました。
その２：命名規則は統一するべし
命名規則は、システム全体の可読性と保守性を決定する重要な要素です。
たとえば、あるプロジェクトで以下のようなテーブル名を見つけたとします。
|
1 2 3 4 5 6 |
User -- 単数形 order_details -- スネークケース CustomerInfo -- キャメルケース t_product -- 接頭辞あり payment -- 接頭辞なし |
このように命名規則がバラバラだと、開発者は「このテーブル名はどう書くんだっけ？」と毎回迷うことになります。また、新しいメンバーがプロジェクトに参加した際の学習コストも高くなってしまいます。
本プロジェクトで定義した基本的な命名ルール:
- テーブル名は集合名詞・複数形で記載（例：
users,orders） - 半角アルファベット、数字、アンダーバーのみ使用
- 名前の先頭はアルファベット
- システム全体で命名の一貫性を保つ
- スネークケースを採用
接頭辞の活用例:
|
1 2 3 4 5 6 7 8 9 |
-- マスタテーブル m_users, m_products, m_categories -- トランザクションテーブル t_orders, t_payments, t_shipments -- リレーションテーブル rel_user_role, rel_product_category |
接頭辞を使うことで、テーブルの役割が一目で分かるようになり、開発効率が向上するという利点も学べました。
その３：データの整合性を保つべし
データの整合性を保つための主要なチェックポイントでは、特に重複レコードの防止について詳しく説明します。
たとえば、以下のような顧客テーブルがあったとします。
|
1 2 3 4 5 6 7 |
CREATE TABLE customers ( id INT AUTO_INCREMENT PRIMARY KEY, email VARCHAR(100), name VARCHAR(100), phone VARCHAR(20) ); |
この設計では、同じメールアドレスで複数のレコードが作成される可能性があります。
|
1 2 3 |
INSERT INTO customers VALUES (1, 'taro@example.com', '田中太郎', '090-1234-5678'); INSERT INTO customers VALUES (2, 'taro@example.com', '田中太郎', '080-9876-5432'); -- 重複！ |
このような重複を防ぐために、ユニーク制約を設定します。
|
1 2 3 4 5 6 7 |
CREATE TABLE customers ( id INT AUTO_INCREMENT PRIMARY KEY, email VARCHAR(100) UNIQUE NOT NULL, -- ユニーク制約を追加 name VARCHAR(100) NOT NULL, phone VARCHAR(20) ); |
その他の重要な整合性確保のポイントは以下の通りです：
- 識別子の統一: ID・コードの形式とルールの一貫性
- NOT NULL制約: 必須項目への適切な制約付与
- データ型の適切性: IDには
BIGINT、日付にはTIMESTAMPなど - カラムの分割: 「名前」を「姓」「名」に分割するなど、意味のある単位での設計
- チェック制約: 業務ルールに基づく値の範囲制限
3. 実施したレビュー手順
これらのテーブル構成の観点を踏まえ、以下の手順でレビューを行いました。
Step 1: 全体像の把握
- テーブル一覧を眺めて、システム全体の構造を理解
- 主要なエンティティの関係を把握
Step 2: 基本構造のチェック
- 各テーブルの役割が明確か
- 主キーが適切に設定されているか
- データ型が適切か
Step 3: 命名規則の確認
- テーブル名・カラム名の一貫性
- 接頭辞・接尾辞のルール統一
Step 4: 整合性確認
- 必要な制約が設定されているか
- 外部キー関係が適切か
4. 最後に
「何をチェックすればいいかわからない」と感じていた最初の状態から、実際にレビューを経験することで、確認すべきポイントが見えてきました。
最も大切だと感じたのは、「この設計が原因でバグが起きたり、後から修正が大変になるような作りになっていないか」を常に意識することでした。
テーブルの役割を明確にし、命名規則を統一し、データの整合性を保つ。この3つの基本を押さえることで、保守性の高いデータベース設計につながることを学べました。
同じように「初めてレビューを任されたけど、何を見ればいいかわからない」と悩んでいる方にとって、少しでもヒントになれば嬉しいです。
最後までお読みいただきありがとうございました。
また、エコモットでは一緒にモノづくりをしていく仲間を随時募集しています。
弊社に少しでも興味がある方はぜひ下記の採用ページをご覧ください！
