ポイントの管理を行うDBの構造はどんなものがあるか

・グループM 　　↓ 　・店舗マスタ 　　　↓ 　　　・ポイント利用テーブル

・ユーザM

なぜグループマスタが必要か

例

ワタミ（グループマスタ） ↓ →東京店 　↓ 　・3/1 　・3/20 →横浜 　↓ 　・3/5 　・3/6

---

基本的なポイントの動き

• 売上 → 加算
• ポイント消化 → 減算
• ボーナス、キャンペーン → 加算

---

ワタミ（グループマスタ） ↓ →東京店 ↓ →横浜店

つぼ八（グループマスタ） ↓ →東京店 ↓ →横浜店

店同士は互換性があるが、企業が異なる場合をあとであわせて管理することになったとき...

例：ワタミ→100p、つぼ八→80p

これの互換性、コンバートをしやすくするときは、店舗マスタではなく、グループマスタとして管理しておく

発展形

グループマスタの上に「業種マスタ」を追加してもよい

薬局グループでためたポイントを、居酒屋でポイントを使いたいなどの変更が可能

居酒屋→ワタミ（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

居酒屋→つぼ八（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

-----------------------------------

薬局→HAC（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

薬局→スギ薬局（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

ポイントのレートを意識するとき、店舗マスタにレートをもつほうが適切かも検討する

どうやってマネタイズするか

このアプリ導入についてはQRコードで配布

Webサイト 持ち込み ↓ 専用のQR表示 ↓ 使用可能（システムは使える・ポイントは貯められるけど、セキュリティ的に使うことはできない） ーーー仮審査おわりーーー ↓ 本審査 ↓ OKならレート交換

---

入力部分はデータベースとは関係ないけど一番むずかしいところ。

ペイペイは手入力を許したことで勝てた

入力

• POSレジ連携
• 手入力

---

自分が何をやりたいのかから考え始める

---

• 手入力の不正を防ぐ

例：id, shop, data, pointカラム以外、ランダムな16桁の数値（可逆的なハッシュ値）

ハッシュ値はid, shop, data, pointをキーに生成し、

変更が不正なものの場合、このレコードを無効にする対策を行う

ハッシュ値を深くすると激重になる

---

レコード数が爆発的に多くなるのでスピードをだすときは

id	user	shop	data	point
1	100	50	0318	10000
2	101	70	0318	700
3	130	30	0318	-100
4	100	50	0319	-560

ind...1 user shop date

ind...2 user date shop

id	user	shop	data	hour	time	point
1	100	50	0318	09	19	10000
2	101	70	0318	11	05	700
3	130	30	0318	12	34	-100
4	100	50	0319	18	30	-560

ある日の何時から何時までの売上を管理するとかだと、時間も切り出してレコードに保存する

計算はデータベースに計算させないほうがいい場合もあるので、アプローチは考える必要がある

インデックスをはるのは最低限にする（メモリ食う）

どういう集計するかでインデックスや工夫の余地がある

---

アンケートについて考える

アンケートを構成するもの

• 文字入力
• 文章入力
• 選択
  • プルダウン
  • 単一選択
  • 複数選択
• 他

テーブル構成

アンケートテーブル

• id
• アンケート名
• 回答期限
  • 回答期限From
  • 回答期限To
• 誰が

アンケート本体テーブル

• id
• アンケートid
• 行番号
• 設問名
• 入力方法
• プルダウンなどの場合、選ばれた選択肢

回答テーブル

• id
• アンケート本体id
• ユーザid
• 回答

---

DBだけで集計するのは難しいので、SQLで吐き出したデータをプログラムで集計させるほうがこの構造だといいかも