postgresql-table-design
専門家のガイダンスでPostgreSQLスキーマを設計する
PostgreSQLスキーマ設計には、データ型、インデックス戦略、制約、パフォーマンスパターンに関する知識が必要です。このスキルは、効率的で保守性の高いデータベーススキーマ構築を支援する、PostgreSQL固有のベストプラクティス、高度な機能、一般的な落とし場についての包括的なガイダンスを提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「postgresql-table-design」を使用しています。 PostgreSQLで monetary 値を保存するにはどうすればよいですか？
期待される結果:
monetary 値にはNUMERIC(p,s)を使用し、floatタイプは決して使用しないでください。たとえば、2桁の精度の通貨にはamount NUMERIC(10,2)を使用します。これにより、浮動小数点の精度問題なしに正確な10進演算が提供されます。非推奨のmoneyタイプは避けてください。
「postgresql-table-design」を使用しています。 BIGINT GENERATED ALWAYS AS IDENTITYとUUID、主キーの違いは何ですか？
期待される結果:
- BIGINT GENERATED ALWAYS AS IDENTITY: 連続する整数ID。ほとんどのユースケースで推奨されます。利点: ストレージが小さくなる、インデックスが高速になる、ローカリティが向上する。システム間でのグローバルな一意性が不要な場合に使用してください。
- UUID: グローバルに一意な識別子。複数のデータベースからデータをマージする場合、フェデレーションシステムを構築する場合、または不透明で非連続のIDが必要な場合に使用してください。PostgreSQL 18以降ではuuidv()で、古いバージョンではgen_random_uuid()で生成してください。
「postgresql-table-design」を使用しています。 外部キーカラムにインデックスを追加すべきですか？
期待される結果:
はい、外部キーカラムには常に明示的なインデックスを追加してください。PostgreSQLは一部のデータベースとは異なり、FK列に自動インデックスを作成しません。これにより、結合が高速化され、親テーブルの削除や更新時のロック問題を防げます。例: user_id外部キーに対してCREATE INDEX ON orders (user_id)を作成してください。
セキュリティ監査
安全This skill is a documentation-only resource providing PostgreSQL schema design guidance. All 237 static findings are false positives triggered by SQL examples and technical terminology in markdown code blocks. The skill contains no executable code, network calls, or file system access. Safe for publication.
品質スコア
作れるもの
新しいデータベーススキーマの設計
アプリケーション用の新しいPostgreSQLデータベースを設計する際に、テーブルの構造、データ型、制約、インデックス戦略に関するガイダンスを受けてください。
既存のスキーマパフォーマンスの最適化
クエリパフォーマンスの向上とデータベースの膨張を減らすために、インデックス戦略、パーティションオプション、パフォーマンスパターンについて学びます。
スキーマ設計の決定をレビュー
実装前に、PostgreSQLのベストプラクティスに対してデータ型の選択、制約の使用、正規化の決定を検証します。
これらのプロンプトを試す
メール、名前、タイムスタンプを持つユーザーテーブルを作成する必要があります。推奨されるPostgreSQLスキーマは何ですか？
製品の価格、IPアドレス、ユーザーの設定を保存しています。どのようなPostgreSQLデータタイプを使用すべきですか？
ordersテーブルはuser_id、status、created_atでフィルタリングするクエリがあります。どのようなインデックスを作成すべきですか？
毎日数百万件のセンサーデータを保存する必要があり、デバイスと時間範囲でクエリをフィルタリングします。スキーマとパーティショニングをどのように設計すべきですか？
ベストプラクティス
- 正規化された第3正規形のスキーマから始めて、特定の高価値なクエリで測定されたパフォーマンス問題がある場合にのみ非正規化してください
- すべてのタイムスタンプ列にはTEXTにはTEXTを、文字列にはNUMERICを、プライマリキーにはBIGINT GENERATED ALWAYS AS IDENTITYを使用し、UUIDが必要な場合を除いてTIMESTAMPTZを使用してください
- WHERE句、JOIN条件、ORDER BY句で使用される列にインデックスを作成し、外部キーカラムには常に明示的なインデックスを追加してください
回避
- VARCHAR(n)やCHAR(n)データタイプは使用しないでください。必要な場合はCHECK制約で長さ制限を適用したTEXTを使用してください
- タイムゾーンなしのTIMESTAMP、moneyタイプ、SERIALは使用しないでください。代わりにTIMESTAMPTZ、NUMERIC、GENERATED ALWAYS AS IDENTITYを使用してください
- 実際のパフォーマンス問題を測定する前にデータを非正規化しないでください。 premature な非正規化は、証明された利点なしに保守の負担を作成します