必要なモデルの洗い出し

[Yoshino-Yukitaro]

概要

大まかな画面がわかったため、必要なモデル(DBスキーマ兼エンティティ)の洗い出しを進めたいです。

ユースケースからじっくり考えるのは時間がかかりますし、今回はいきなりモデルを考えるところから進めたいです。 まだ仕事中なので、退勤したらサラ〜っと今考えているものをmermaidで書いてみます。

[Yoshino-Yukitaro]

やっぱり一旦文字でかく(型はめんどければ全部int, varchar255, doubleとかで良いかもしれない。。)

前提(クライアントとも要相談)

• カテゴリ(散歩、サウナ、ご飯)はinmemoryで良さそう。どうせ検索にしか使わない
• 目的地の位置情報とかもクライアント管理で良さそうな気がする
• 美少女のセリフもクライアント管理で良さそう
• 通知タイミングの保存をどこにするかでインフラが変わる
  • アプリない保存 -> アプリない通知
  • サーバー保存 -> Amazon SNSやFirebase cloud messagingが必要
• 髪型とかテーブル分割しないで良いかも。参照頻度とか考えなくて良いし
• 「所有テーブル」みたいなのも考えなくて良いかも。利用者1人ならカラム表現できる
• indexは10000レコードもない環境だと寧ろ遅くなるので不要
• 「チバニャンの」みたいな識別子も不要。どのみち使用するのはチバニャン。

beauty_girls

• id(bigint, PK, unsigned, auto_increment)
• rank(smallint, not null, default 0 or 1, unsigned)
• until_next_rank(int, not null, default 1, unsigne)
• hair_id(int, not null, default 1, unsigned)
• shoes_id(int, not null, default 1, unsigned)
• tops_id(int, not null, default 1, unsigned)
• bottoms_id(int, not null, default 1, unsigned)
• created_at
• updated_at

shoes

• id(int, PK, unsigned, auto_increment)
• name(varchar30くらい, not null, )
• image_url(varchar80くらい, not null, )
• created_at
• updated_at
• is_mine(tinyint1, not null, default 0)

hair

• id(int, PK, unsigned, auto_increment)
• name(varchar30くらい, not null, )
• image_url(varchar80くらい, not null, )
• created_at
• updated_at
• is_mine(tinyint1, not null, default 0)

tops

• id(int, PK, unsigned, auto_increment)
• name(varchar30くらい, not null, )
• image_url(varchar80くらい, not null, )
• created_at
• updated_at
• is_mine(tinyint1, not null, default 0)

bottoms

• id(int, PK, unsigned, auto_increment)
• name(varchar30くらい, not null, )
• image_url(varchar80くらい, not null, )
• created_at
• updated_at
• is_mine(tinyint1, not null, default 0)

[ryichk]

みんなで決めた方が良さそうなこと

• [x] 好感度ランクのロジック (4/11に決めた)

  • 目的地に着くと好感度は何ポイント上がるのか？
  • 近い：50ゲージ
  • 中間：100ゲージ
  • 遠い：200ゲージ
  • 好感度が何ポイントで１ランク上がるのか？
  • 前提：ランク8 -> ランク9だけ実装する
    • ランク８：800が最大値
    • ランク９：900が最大値
  • 好感度は上がるだけで下がらないのか？
  • 下がらない。

• [x] アイテムの種類

  • 髪型、シューズ、トップス、ボトムスの４つで良いか？

エンジニアで決めた方が良さそうなこと

• [x] 女の子の画像やアイテムの画像はどう管理する？ (4/9に決めた)
  • 女の子の画像
  • クライアント管理
  • 5~6枚ならビルド速度に影響しない（キャッシュあり）
  • アイテム画像（種類多い）
  • サーバー（Cloud Storage）
  • その他UI関連の画像
  • クライアント管理
• [x] 一度訪れた場所をどう管理する？
  • そもそも管理しない？
  • 管理する場合
  • Google mapにplace_idというのがあるので、これをテーブルで管理すれば良いかも

[iineineno03k]

1度訪れた場所の管理のために、選択された場所はDBに保存した方がよさそうですね ランダムに選ばれた場所が訪問済テーブルに含まれるか確かめて、含まれてたら再度ランダム取得するみたいな。

[Yoshino-Yukitaro]

女の子の画像やアイテムの画像はどう管理する？

個人的にはアイテムの画像はiOSのビルドサイズを下げるためにもサーバー管理で良い気がしていますがどうでしょう？ 🤔 管理場所についてはリクエストがほぼ来ないことを考えるとRailsでも良いのですが、CDNのキャッシュ機構を用いてデモの時の体験を高めるならCloud Storageが必須になるかもしれません :eyes: 体験をどの程度良くする？みたいなのはエンジニアで決めたいです(わからない人からしたら「わからんけど常に最高で！！」ってなりますし。。)

一度訪れた場所をどう管理する？

1度訪れた場所の管理のために、選択された場所はDBに保存した方がよさそうですね ランダムに選ばれた場所が訪問済テーブルに含まれるか確かめて、含まれてたら再度ランダム取得するみたいな。

自分も管理することに賛成です！(完全に加え忘れてました :sweat_drops:) 市来さんが提案してくださったplace_idは管理に使えそうですね！ 名前などのデータはGoogleのAPIの情報を使用すれば良いですし、重複排除にしか使用しないならテーブルはこんな感じになりますかね？ 🤔

visited_places

• id(int, PK, unsigned, auto_increment)
• place_id(varchar30くらい(要確認), not null, UK)
• created_at
• updated_at

[Yoshino-Yukitaro]

📝 美少女(beauty_girls)のnameを削除しました