レベルアップシステムを実装したい

Question

レベルアップ機能を実装するさいのテーブル設計

現在、railsを使ってタスクを完了したら経験値がたまり、レベルアップするアプリを作っている途中なのですがテーブル設計がわからなく、過去の同じような質問などをみて参考にして書いているのですが自分の場合はどうなのだろうかとなかなか進みません。
devisuによりログイン機能がついており、タスクを入力したら一覧に表示し、タスクが完了したら消すことができるツイート投稿型アプリと構造が同じです。
ちなみにその部分までは完成しており、レベルアップ機能を追加で実装しようとしている段階です。
タスクを消したら経験値を手に入れてレベルアップという流れにしたいです。
以下のテーブル設計についてご教授いただけたら幸いです。言語はrubyです。

自分で書いてみたテーブル設計

## users テーブル

| Column       | Type       | Options                 |
| ------------ | ---------- | ----------------------- |
| name         | string     | null: false             |
| email        | string     | null: false             |
| password     | string     | null: false             |
| player_level | integer    | null: false, default: 1 |
| exp          | integer    | null: false, default: 0 |
| level_id     | references | foreign_key: true       |

## Association

- has_many :tasks
- belongs_to :level


## tasks テーブル

| Column  | Type       | Options                        |
| ------- | ---------- | ------------------------------ |
| content | string     | null: false                    |
| point   | integer    | null: false, default: 1        |
| user_id | references | foreign_key: true              |

## Association

- belongs_to :user


## レベルテーブル

| Column    | Type       | Options                        |
| --------- | ---------- | ------------------------------ |
| level     | integer    |                                |
| threshold | integer    |                                |

## Association 

- has_many :users

補足情報

userのexpはtaskのpointと連動して経験値をもらえる仕組身にしようとしています。

Comments

[m.ts10806]

タイトル、タグですが、あまりRailsに特化しなくて良いとは思います。確かに名称など制約は受けるでしょうけど、設計段階ではあまり考慮しすぎなくても良いとは思います。

[kdh]

ありがとうございます。タグやタイトルなど修正してみます。

[phper.k]

プログラミング言語やフレームワークはお使いですか？
使っているようであればフレームワーク名も

[kdh]

ありがとうございます。質問に追記しました。

Answer 1

Ruby　および Ruby on Rails は門外漢なのですが、修正依頼をした行きがかり上、回答します。

Users

• users テーブルに exp は不要
• level_id は場合によって不要

Column	Type	Options
id	integer	null: false, ai
name	string	null: false
email	string	null: false
password	string	null: false
player_level	integer	null: false, default: 1
exp	integer	null: false, default: 0
level_id	references	foreign_key: true

• exp が不要なのは、

SELECT sum(tasks.point)` FROM users 
LEFT JOIN tasks ON users.id = tasks.user_id
GROUP BY users.id

で取得可能だし、終了したタスクが増えるたびに、users テーブルを更新する無駄が発生するから。
フレームワークにバンドルされているORMでも取得可能でしょう。

Tasks

Column	Type	Options
id	integer	null: false, ai
content	string	null: false
point	integer	null: false, default: 1
user_id	references	foreign_key: true
is_finished	bool	default: false

タスクが終了したのかどうかを判定するカラムは不要？（要件次第だからなんともいえないけど。）
タスク完了の日時でも良いと思う。その場合のカラム名は、finished_at とかが適当でしょう。

levels

Column	Type	Options
id	integer	null: false, ai
level number	integer
threshold	integer

合計のポイントからSQLで現在のレベルを判定することもできる。
（Having とか使ってもっと効率的に取得すべきだけど。）
場合によって、users に level_id がいらないと言ったのはこれが理由

SELECT 
    users.*,
    sum(tasks.point),
    (SELECT name FROM levels WHERE threshold <= sum(tasks.point) LIMIT 1) as level
FROM users, levels
LEFT JOIN tasks ON users.id = tasks.user_id
GROUP BY users.id

Comments

[kdh]

ありがとうございます。SQLの方はSequel Proのクエリで抽出されるものを確認する程度しかやったことがないですが、ターミナルで打ち込んでいくのでしょうか？

[phper.k]

Sequel Proで確認すればいいと思いますよ。

[kdh]

わかりました。ありがとうございます！

[kdh]

質問失礼します。
SELECT sum(tasks.point)` FROM users
LEFT JOIN tasks ON users.id = tasks.user_id
GROUP BY users.id
をSequel Proで確認したところ真ん中の列はNULLでした。これはusersテーブルとtasksテーブルのレコードの数があっていないからなのでしょうか？
またrailsでこのSQL文をどのように使ったらいいのでしょうか？
rails　SQL使い方　で検索しましたが出てこないので質問させていただきます。お時間ある時でいいのでよろしくお願いいたします。

[phper.k]

railsのことはわかりません

Answer 2

レベルアップシステムってキーワードで、イベントソーシングって方法をぜひ紹介したくて、回答を書くことにしました。私自身は全く詳しくありませんｗ

PHPとEventSauceで始めるイベントソーシングアプリケーション

資料内のコードは php ですが、概念だけ見てください＾＾；
かなり衝撃的です。

Comments

[kdh]

学習して2ヶ月なので、phpは初見でしたがここに書かれていることはJavaScriptに似ていますね！内容は難しかったですがw
しかし有益な情報ありがとうございます！

Answer 3

tasksテーブルのuser_idは、誰が何のタスクを記録するためのものでしょうか？

であれば、テーブルを分割したほうが良いと思います。

tasks テーブル

Column	Type	Options
content	string	null: false
point	integer	null: false, default: 1
task_id	integer

tasks_users テーブル

Column	Type	Options
task_id	integer
user_id	integer

Comments

[kdh]

回答ありがとうございます。
tasksテーブルのuser_idはdeviseを導入しているので、各ユーザーとそのユーザーが設定したタスクを紐付けるものです。ユーザがタスクを自分で決めて投稿するような、構造はツイート投稿型のアプリに似ています。
なのでアソシエーションの関係が1対多なのですがそれでも分割した方がよろしいでしょうか？
中間テーブルは多対多のときに使うものだと思っていたもので。。。

[Kaiser]

承知しました。kdh提示されている構造で特に問題無いと思います。