database-design について
リレーショナルデータベースを扱う開発者向けの設計スキルです。正規化、インデックス、移行、クエリ分析、データ整合性を、PostgreSQLの例とともに扱います。
主な機能
- 01正規化と非正規化の適用
- 02インデックスの設計と分析
- 03安全な移行とゼロダウンタイム移行の計画
- 04EXPLAINによるクエリ最適化
- 05データ整合性制約の設定
活用シーン
- 01リレーショナルスキーマの設計
- 02遅いデータベースクエリの改善
- 03停止時間を抑えたスキーマ変更の展開
- 04インデックス利用と移行の安全性確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ eddiebe147/ claude-settings --skill database-designインストール後、Claude Code で/database-designを入力して読み込まれたか確認します。
詳細
データベース設計
スキーマ設計の原則
正規化のガイドライン
-- 1NF: Atomic values, no repeating groups
-- 2NF: No partial dependencies on composite keys
-- 3NF: No transitive dependencies
-- Users table (normalized)
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Addresses table (separate entity)
CREATE TABLE addresses (
id SERIAL PRIMARY KEY,
user_id INTEGER REFERENCES users(id) ON DELETE CASCADE,
street VARCHAR(255),
city VARCHAR(100),
country VARCHAR(100),
is_primary BOOLEAN DEFAULT false
);
パフォーマンス向上のための非正規化
-- When read performance matters more than write consistency
CREATE TABLE order_summaries (
id SERIAL PRIMARY KEY,
order_id INTEGER REFERENCES orders(id),
customer_name VARCHAR(255), -- Denormalized from customers
total_amount DECIMAL(10,2),
item_count INTEGER,
last_updated TIMESTAMPTZ DEFAULT NOW()
);
インデックス設計
一般的なインデックスパターン
-- B-tree (default) for equality and range queries
CREATE INDEX idx_users_email ON users(email);
-- Composite index (order matters!)
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at DESC);
-- Partial index for specific conditions
CREATE INDEX idx_active_users ON users(email) WHERE deleted_at IS NULL;
-- GIN index for array/JSONB columns
CREATE INDEX idx_posts_tags ON posts USING GIN(tags);
-- Covering index (includes additional columns)
CREATE INDEX idx_orders_covering ON orders(user_id) INCLUDE (total, status);
インデックス分析
-- Check index usage
SELECT
schemaname, tablename, indexname,
idx_scan, idx_tup_read, idx_tup_fetch
FROM pg_stat_user_indexes
ORDER BY idx_scan DESC;
-- Find missing indexes
SELECT
relname, seq_scan, seq_tup_read,
idx_scan, idx_tup_fetch
FROM pg_stat_user_tables
WHERE seq_scan > idx_scan
ORDER BY seq_tup_read DESC;
マイグレーションパターン
安全なマイグレーションテンプレート
-- Always use transactions
BEGIN;
-- Add column with default (non-blocking in PG 11+)
ALTER TABLE users ADD COLUMN status VARCHAR(20) DEFAULT 'active';
-- Create index concurrently (doesn't lock table)
CREATE INDEX CONCURRENTLY idx_users_status ON users(status);
-- Backfill data in batches
UPDATE users SET status = 'active' WHERE status IS NULL AND id BETWEEN 1 AND 10000;
COMMIT;
ダウンタイムなしのマイグレーション
1. Add new column (nullable)
2. Deploy code that writes to both columns
3. Backfill old data
4. Deploy code that reads from new column
5. Remove old column
クエリの最適化
EXPLAIN 分析
-- Always use EXPLAIN ANALYZE
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';
-- Key metrics to watch:
-- - Seq Scan vs Index Scan
-- - Actual rows vs Estimated rows
-- - Buffers: shared hit vs read
一般的な最適化
-- Use EXISTS instead of IN for large sets
SELECT * FROM users u
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
-- Pagination with keyset (cursor) instead of OFFSET
SELECT * FROM posts
WHERE created_at < '2024-01-01'
ORDER BY created_at DESC
LIMIT 20;
-- Use CTEs for complex queries
WITH active_users AS (
SELECT id FROM users WHERE last_login > NOW() - INTERVAL '30 days'
)
SELECT * FROM orders WHERE user_id IN (SELECT id FROM active_users);
制約とデータ整合性
-- Primary key
ALTER TABLE users ADD PRIMARY KEY (id);
-- Foreign key with cascade
ALTER TABLE orders ADD CONSTRAINT fk_orders_user
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
-- Check constraint
ALTER TABLE products ADD CONSTRAINT chk_price_positive
CHECK (price >= 0);
-- Unique constraint
ALTER TABLE users ADD CONSTRAINT uniq_users_email UNIQUE (email);
-- Exclusion constraint (no overlapping ranges)
ALTER TABLE reservations ADD CONSTRAINT excl_no_overlap
EXCLUDE USING gist (room_id WITH =, tsrange(start_time, end_time) WITH &&);
ベストプラクティス
- 公開向け ID には UUID を、内部用には SERIAL/BIGSERIAL を使用します
created_atとupdated_atのタイムスタンプを必ず追加します- 重要なデータには論理削除(
deleted_at)を使用します - 分散システムでは結果整合性を考慮して設計します
- マイグレーションファイルにスキーマ決定の内容を記録します
- デプロイ前に本番環境と同規模のデータでマイグレーションをテストします
コメント
Markdown 対応