ユニーク制約カラムを持つシードデータ
シードジェネレーターがemailやusernameのようなUNIQUEカラムを処理する方法を学びます。衝突確率と大規模データセットの戦略を理解します。
Advanced
詳細な説明
ユニーク制約の考慮事項
UNIQUE制約を持つカラムはすべての値が異なる必要があります。シードジェネレーターは衝突を最小化するために高い分散でデータを生成しますが、厳密な一意性は強制しません。
ユニークカラムの生成方法
ジェネレーターには特別な「ユニークモード」はありません。代わりに、データプールの大きな組み合わせ空間に依存します:
| カラム型 | 組み合わせ空間 |
|---|---|
| 40名前 × 40姓 × 99番号 × 10ドメイン = 15,840,000 | |
| Username | 40名前 × 999番号 = 39,960 |
| UUID | 16^32 ≈ 3.4 × 10^38 |
| Phone | ~800市外局番 × 900中間 × 9000末尾 > 60億 |
衝突確率
一般的なシードサイズ(10〜1,000行)では、衝突確率は無視できるほど小さいです:
- 10行: 衝突の可能性はほぼゼロ
- 100行: メールの衝突は0.1%未満
- 1,000行: メールの衝突は1%未満、まだ稀
衝突が発生した場合
生成されたINSERT文を実行してユニーク制約違反が発生した場合:
- 再生成: Regenerateをクリックして新しいランダムシードを取得し、完全に異なるデータを生成
- 行数削減: 衝突確率を下げるために行数を減らす
- UNIQUE制約を一時的に削除: CREATE TABLE入力からUNIQUE制約を削除し、データを生成してから制約を戻す
UUIDカラム
UUID型のカラム(またはuuidという名前のカラム)では、ジェネレーターはRFC 4122形式のUUIDを生成します。空間が非常に広いため、実用的な行数では衝突は統計的に不可能です。
実用的な推奨
1,000行までのほとんどの開発・テストシナリオでは、ユニーク制約の衝突は極めてまれです。特殊な一意性要件を持つカラム(例:短いコード、2文字の略語)のデータを生成する場合は、JSON出力を使用して重複を除去する後処理を検討してください。
ユースケース
usersテーブルにemailとusernameの両方にUNIQUE制約があります。生成されたシードデータを実行する前に、特に負荷テストで500行以上を生成する際に、衝突がどの程度発生しやすいか、発生した場合にどうすべきかを理解したいです。