database-design
データベース設計とスキーマ決定をマスターする
開発者はデータベースの選択とスキーマ設計の落とし穴に苦しみます。このスキルは、文脈に基づいてデータベースを選択する方法、スキーマを設計する方法、クエリを最適化するたの判断フレームワークを教えます。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「database-design」を使用しています。 10,000人の同時ユーザー、グローバル分散、サブ50ミリ秒レイテンシ要件を持つリアルタイムチャットアプリケーションのデータベースを選択する必要があります。
期待される結果:
厳格なレイテンシ要件を持つグローバルリアルタイムチャットには、Turso（エッジSQLite）をプレゼンスとメッセージメタデータ用に、主となるPostgreSQLインスタンスを耐久性のあるストレージ用に組み合わせることを検討してください。Tursoはレイテンシを削減するエッジデプロイを提供し、PostgreSQLは複雑なクエリとトランザクションを処理します。代替案：グローバルブランanking対応のMySQL互換PlanetScale。
「database-design」を使用しています。 ユーザープリファレンステーブルを正規化するべきですか、それともJSONBとして保存すべきですか？
期待される結果:
JSONBとして保存する場合：個別のプリファレンスが頻繁にクエリされない場合、スキーマが頻繁に进化する場合、完全なセットを常に取得する場合。正規化する場合：WHERE句で特定のプリファレンスをクエリする必要がある場合、異なるプリファレンスの更新頻度が異なる場合、外部キー制約が必要な場合。ハイブリッドアプローチ：頻繁にフィルタリングされる設定用の正規化テーブルと、柔軟なプリファレンス用のJSONB。
セキュリティ監査
安全All static analyzer findings are false positives. The 'external_commands' detections are markdown code fence blocks (```) used for educational diagrams, not executable shell commands. The 'weak cryptographic algorithm' flags reference UUID/ULID discussions in documentation context. The schema_validator.py is a legitimate local Python script for Prisma schema validation. This is a documentation-only skill teaching database design principles.
品質スコア
作れるもの
新規プロジェクトのデータベースセットアップ
MVPを構築するスタートアップ創業者がPostgreSQL、SQLite、サーバーレスタイプの選択肢から選ぶためのガイダンスを必要としています。このスキルは、スケーラビリティの必要性、予算、デプロイメントの好みに基づいて判断ツリーを提供します。
スキーマ設計レビュー
新機能を設計するバックエンドエンジニアがユーザーリレーションシップ、タイムスタンプ、外部キー制約のモデル化を手伝ってほしいと考えています。このスキルは正規化のトレードオフとリレーションパターンについてレビューします。
クエリパフォーマンスのトラブルシューティング
低速なクエリに苦しむ開発者がインデックス戦略とN+1問題について理解する必要があります。このスキルはEXPLAIN ANALYZEの解釈と複合インデックス設計について説明します。
これらのプロンプトを試す
{project_type}アプリケーションを構築しており、ユーザーは{expected_users}人、予算は{budget_level}、{specific_requirements}が必要です。データベース選択ガイドに基づいて、最適なデータベースオプションを推奨し、トレードオフを説明してください。{table_name}テーブルのスキーマ設計をレビューしてください。{data_fields}を保存する必要があり、{related_tables}との関係があります。私のアプローチが正規化の原則に従っているか、適切なインデックスがあるか、正しい関係タイプを使用しているかをチェックしてください。{query_description}のクエリが{execution_time}かかっています。EXPLAIN ANALYZEの出力は次の通りです：{explain_output}。ボトルネックを特定し、具体的なインデックスやクエリ再構築戦略を推奨してください。ベストプラクティス
- 常にTIMESTAMPTZを使用してタイムゾーン対応の作成日時と更新タイムスタンプを定義する
- 分散システムでは列挙攻撃を避け、オフラインID生成を可能にするためにUUIDまたはULID主キーを使用する
- 最も一般的なクエリパターンに一致する複合インデックスを作成し、等価列を範囲列の前に配置する
回避
- シンプルなアプリケーションでPostgreSQLをデフォルトで使用し、不必要なインフラストラクチャ複雑性を追加する
- 書き込みパフォーマンスへの影響と低カーディナリティの非効率性を考慮せずにすべての列にインデックスを作成する
- 必要な列を明示的に選択する代わりに本番環境クエリでSELECT *を使用する