個人開発で予約システムを設計しており、
アカウント登録なしでも予約を行えるような設計にしたいと考えています。
予約テーブルにユーザーID（null許可）を持たせ、、
アカウント登録者 → 予約テーブルのユーザーIDにそのままユーザーIDを入れる
非アカウント登録者 → 予約テーブルのユーザーIDにはnullを入れる
上記のようなイメージの設計を考えましたが、外部キーとなるIDにnullが入ってしまうのはNGになると思うので、こうした場合のベストプラクティスをご教示いただけないでしょうか。
あらゆる世の中の予約サイトのDBはどのような設計になっているのでしょうか。
経験が浅く、お力添えください。よろしくお願いします。
設計についてはケースバイケースなので、明らかなアンチパターンはあっても、ベストプラクティスを回答するのはなかなか難しいように思えます。
「予約」という業務自体がサービスや事業で様々だと思うので。
個人開発の小さなアプリケーションなら「ユーザーIDをnull」にするのも許容できるかもしれませんし、商用としてアップデートを続けていくなら許容できないかもしれません。
アカウント登録の有無で差別化を図るなら予約テーブル自体を別にするかもしれません。
「予約」自体も様々な状態があるので、複数のテーブルで構成されるかもしれません。
テーブル設計についての参考資料を貼っておきます。
もちろんこの考え方が全てというわけではないので、考えを広げるためのヒントとして。
@blue32a 氏 の回答が殆ど全てだと思います。
それを踏まえた上で(蛇足…かもしれない)
私なりのパッと思いついた方法を回答をいたします。
個人開発で予約システムを設計しており
上記について、責任問題に発展しない範囲で
「動作確認をしたい」レベルの話になります。
IDの衝突を「絶対に避けられる」訳ではないけど
「おおよそ回避できる」かもしれない方法です。
■提案
(1)IDを年月日～予約した瞬間のミリ秒までを連結した数字の列にする
(2)IDの範囲を大幅に分ける
例えば、サイトの規模的にアカウント登録者を0～9999までしか
見込まない場合、100000～を非アカウント登録者の番号とし、
100000からインクリメントする
どちらも確実ではないうえに、褒められた方法ではないですが、
「ユーザーIDをnull」にするよりは良いのではないかと思います。
(ソートする際にも役立つかと思われます)
@blue32a さん
@syutorum001 さん
わかりやすく的確なご回答をいただきありがとうございます。
ご提供・ご提案いただいた情報にも目を通し、非常に勉強になりました。
この質問投稿後も似たような事例がないかと色々と探っていたところ、下記の記事を見つけました。
個人的にですが、こちらの記事の途中で教科書通りとも記載されている、中間テーブルを使用する方法がかなりしっくりときました。
もし、この方法にも落とし穴がある等のご指摘がありましたら、お教えいただけますと幸いです。
