レコードに合った ID の種類を選ぶ
テーブルや API 向けに ID の種類を比較し、理由を添えて一つを勧めるプロンプト。お好きなAIツールに貼り付けると、AIがID の種類を選ぶ。
- テーマ
- アプリ・プロトタイプ
- 種類
- プロンプト
- レベル
- 中級
- 所要時間
- 約15分
結果はツール、モデル、入力内容によって変わります。
結果のプレビュー
例：当サイトの編集部が書いたもので、実際のAIの出力ではありません。
| 種類 | 時刻順 | 推測されやすさ | インデックス | | 連番 | はい | 高い | 小 | | ランダム ID | いいえ | 低い | 大 | | 時刻順 ID | はい | 低い | 中 | 推奨: 内部の連番 + 時刻順の公開 ID 列: public_id CHAR(26), 一意
入力する
入力した内容はこのブラウザ画面の中だけにとどまります。当サイトが保存・送信することはありません。
どんなレコードですか?
- 顧客の注文
- ユーザーアカウント
- 機器からのイベント
- リンクで共有する文書
- アプリ間で同期する行
何が最も重要ですか?
- ID を推測されてはならない
- レコードがオフラインで作られる
- 大量でも速い書き込み
- ID を時刻順に並べたい
- 口頭で伝えられる短い ID
システムはどう作られていますか?
- データベースが一つ
- 各サービスが自分のデータベースを持つ
- 同期するモバイルアプリ
- 公開 API
- パートナーのデータを統合する
あなたのプロンプト
プロンプトを編集しました。上の入力欄を変えても、もう上書きされません。
これはAIへの指示文で、まだ完成品ではありません。
このプロンプトが使えるツール
このプロンプトに向いているAIツール：
使い方
- 項目を入力するか、候補をタップします。氏名、住所などの個人情報は入れません。
- 完成したプロンプトをお好きなAIツールに貼り付けます。
- レコードの作成、読み取り、共有の流れを説明してください。サンプルデータよりテーブル定義のほうが役立ちます。
なぜうまくいくのか
他のシステムが保存し始めると、ID の種類はほとんど変えられません。今の十分な検討が、後の大変な移行を防ぎます。
ヒント
- ランダムな ID はアクセス制御の代わりになりません。リクエストごとに必ず権限を確認してください。