観点を決めてコードレビューを頼む
エンジニアが、自分の書いたコードを、正しさ・読みやすさ・安全・性能の観点で見てもらい、直す優先順までつけてもらいたいとき
使う人: 社会人(若手・中堅)・フリーランス・副業
エンジニアが、自分で考えたテーブルの設計を、重複・名前のつけ方・制約・索引・将来の変更のしやすさの面から見直してもらいたいとき(使う人: 社会人(若手・中堅)・フリーランス・副業)
あなたは、業務システムやWebサービスのデータベース設計(テーブル・列・関係の設計)のレビューを数多く行ってきたデータベースの専門家です。 私は自分で考えたテーブルの設計を見直してもらいたいと思っています。立場、作るものの概要、データベースの種類、考えた設計、よくある検索や更新の例、データの件数の見込みは下の記入欄のとおりです。記入欄の内容をもとに、設計を見直してください。
条件: - 同じ情報が複数の場所にないか(正規化)、1つの列に複数の意味を入れていないかを確かめ、直す案を示してください - 主キー、外部キー、一意の制約、空を許すかどうか、初めの値について、抜けや矛盾を指摘してください - テーブルと列の名前のつけ方がそろっているか、型の選び方(日時、金額、真偽)が適切かを見てください - よくある検索に対して、索引が必要な列と、付けすぎによる更新の遅さの注意を書いてください - 削除の扱い(消すか、印をつけるか)、変更の履歴、作成と更新の日時の持ち方を決める観点を示してください - 指摘は「必ず直す・直したほうがよい・好みの範囲」に分け、理由を添えてください - 認証情報(鍵やトークン)・顧客のデータ・社外秘の情報は貼らず、必要な所は伏せ字や作り物の値に置きかえる前提で進めてください 出力は、①指摘の一覧(重さつき)、②直した後のテーブルの案、③索引の案、④確かめたい質問、の順でお願いします。 足りない情報があれば、作業を始める前に質問してください。
同じ情報を1か所だけに持つように、テーブルを分けて整理することです。更新のもれや食い違いを防げます。
検索や並べかえ、結合でよく使う列です。つけすぎると更新が遅くなるため、使い方に合わせて選びます。
後から確かめる必要があるデータは、消さずに印をつける方法があります。保存の期間や法令の決まりも合わせて確かめてください。
最終更新: 2026-10-02(作成: プロンプトン運営事務局・内容は公開時点の一般的な情報です)
エンジニアが、自分の書いたコードを、正しさ・読みやすさ・安全・性能の観点で見てもらい、直す優先順までつけてもらいたいとき
使う人: 社会人(若手・中堅)・フリーランス・副業
エンジニアや開発リーダーが、自社で作って管理しているWebアプリについて、公開の前に守りの抜けがないかを、設計と実装の観点で自己点検したいとき
使う人: 社会人(若手・中堅)・管理職・リーダー・フリーランス・副業
エンジニアや開発リーダーが、本番への公開で失敗しないために、公開の前・最中・後に確かめることと、問題が出た時に元に戻す手順を用意したいとき
使う人: 社会人(若手・中堅)・管理職・リーダー・フリーランス・副業
発注した側の担当者が、開発会社から納められたシステムを、頼んだとおりにできているかを期限内に確かめ、直しの依頼と合否の判断をしたいとき
使う人: 社会人(若手・中堅)・管理職・リーダー・経営者・起業