2025/2/16 DBスキーマを考える会
ここはなに
Akane のDBスキーマを考える会
具体的にどのようなテーブルを作って、どのようなデータを持たせるかを決める
日時
2025/2/16
参加者(CTRL + iでアイコンを置きましょう)
km3.iconretasusan.icontaiseiue.icon
会話ログ
2025/2/17
taiseiue.icon
koto.iconと話していたらどうやらまるまるチェックポイントはないらしい
ないっていうのはどういうことかというと、画面には表示しない
逆に、ヒントは必要かも
昨日決めてしまってる上で手戻りになり申し訳ない
チェックポイントがまるまる失くなるなら工数は削減できるので議題にあげたい
Figmaをみていた
ストーリーには所要時間もいりそう
正確なスキーマを確定するのはFigma完成後かもしれない
昨日の内容で暫定実装初めて、FigmaができたらALTER TABLEするのがいいかも
km3.icon
↑↑↑の発言を受けて考え直した
https://scrapbox.io/files/67b341770646377d54f13eab.png
こんな感じでどないや
具体的な変更としては以下の通りです
checkpointテーブルを削除しました
story_progressionテーブル
current_checkpoint_idカラムを削除
hint_inventoryテーブルを追加
user_account_idとhint_idを持ちます
開封状況などを見ます
questionに以下のカラムを追加
priority => story 内での問題の順番。0なら順序なし
story
radius => 地図に置いたピン座標から半径$ N\text{m}の円
km3.icon
現状決まっていること
ORM には Prisma を使います
MySQL 8.4 を使用する
（手元では）RDBMS に MySQL を使ってました
検討していたこと
km3.icon
脳内にあったスキーマをdumpする
user_account
id
name
やるなら
google_id
email
id
user_account_id => 作成者のID
pin_class => マップ上ピンのアイコン（font-awesomeから選ぶ想定）
type => 長編・短編
status → 公開状態 (public / url_only / private みたいな)
difficulty →自己申告難易度 TINYINT
estimated_time => 所要時間 (VARCHAR)
area => 場所 (VARCHAR)
title
content => 概要的なテキスト
latitude => ピンの緯度
longitude => ピンの経度
image_url => サムネイルの画像
id
story_id => ストーリーのID
priority => 順番
title
content => 問題文
answer => 答え
image_url => 問題に必要な画像（あることもないこともある）
id
content => ヒントの内容
image_url => 手がかりの画像
xcheckpoint（「問」を解くために到達する必要がある場所→手がかり） id
pin_class => ピンのアイコン（font-awesome）から選ぶ感じを想定
question_id=> 問題のID
title => チェックポイント到達前から見えるテキスト
content
image_url => 手がかりの画像
latitude => ピンの緯度
longitude => ピンの経度
id
question_id
hint_id
type => ２種類あるうちのどちらかを判定。詳しくは用語集 priority => 見せる順番（あることもないこともある）（ないなら0）
required_checkpoint_id => このヒントをみるために前提となるチェックポイントのID（ないこともありそう）
id
user_account_id
story_id
status => in_progress/started/cleared それぞれ進行中・開始済み・クリア
current_question_id => 最後に開いた問題。まだ開いてないなら0
current_checkpoint_id => 最後に開いたチェックポイント。まだ開いてないなら0
SQL
code:SQL
CREATE TABLE user_account (
id UNSIGINT NOT NULL,
-- type はユーザーの種類
-- - 0: System とするため使わない
-- - 1: Anonymous 匿名ユーザ
-- - 2: Registered 登録ユーザ(ハッカソンでは作成しなくて良い)
type TINYINT NOT NULL DEFAULT 1,
name VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE story (
id BIGINT NOT NULL
);
km3.iconこれ匿名ユーザーのデータをDBで持つ必要かどうかは検討する必要がある
匿名ユーザはデータを localStorage に入れれば良い
km3.icon 考えていたシナリオとしてはランディングページから、利用規約→名前→スタートみたいな感じなのでその名前入力からスタートに遷移する段階で ID を発行すれば良いだろうと思っていた
km3.icon ID は MySQL の Short_UUID とかでいいでしょうという気持ちです。
km3.icon 匿名ユーザーのデータをDBで持つ利点としては本登録をしたいときはそのまま本登録ユーザーにできるので楽ちん
途中から既存ユーザーにログインするというシナリオはケアしない（＝ログインしたユーザーの情報を優先する）
taiseiue.icon BotかどうかはCFに任せるといけそう
taiseiue.icon
謎、ストーリーとかの関係はここ