Guildシステムの設計

#初めに
　この記事は何かプログラミングについて有用なことを書いてありません。というか誰かにとって有用なものではなくて、僕がGuildについて思考を、もしくは設計をまとめたいから書くだけのものです。
　お気をつけくださいな。

　今回紹介するwebサイトはまだまだ開発段階なので、時々アクセス出来ないでしょうし、エラーコードがまんま出てくることもあると思います。

https://guild.click/message
#概要
　Guildシステムは僕が暇つぶし感覚で開発しているwebサイトです。言語はnode.js、使用しているデータベースはMongoDB。
　それぞれのバージョン(現在2021/8/28)
・node.js　　v15.11.0
・mongodb　4.4.6

　初めは依頼掲示板と銘打ってシステムを組もうと思っていたところ、しかしオンラインでの取引は何が不安かと考えると、相手の信用度と理解度が不安なんだと考えて、そこを補完したシステムを考えました。
　それがGuildシステムです。

　Guildシステムの根幹を成す機能は以下の通り。
・Level機能
・Stamina機能
・Messageギルド等

　Levelは先程言っていた信用のための機能です。Staminaもそんなところ。
　MessageギルドでMessageを投稿することが出来ます。それに対してGoodとかBadを押して相手のLevelを上げたり下げたりすることが出来る様になっています。
　狙い目としては、Levelが信用度としての役割を果たす事です。
　どうしてQuestを頼むことだけを、目的にしていたGuildというシステムで、Messageなんて機能を追加しようと思ったのかというと、それはその人の信用度を確認するためです。
　そのためならTwitterの認証からフォロワー数を取得してきたり、YouTubeのチャンネル登録者を取得してきたり、それをLevelに当てることも良いと考えていますが、検討中です。
#データベースとコレクション
　NoSQLのMongodbではデータの保存の方式にJSONが採用されており、リレーションデータベースのような形を取りません。頑張ったらできないこともないんでしょうけど、難しかったので僕は諦めました。
　またMySQLなどとは違い、「テーブル」ではなくて「コレクション」と呼ばれます。
##User collection
　users collectionに保存するデータです。
　これらの内、followIDs、followerIDsとfavoriteIDsがまだ作れていません。もしかしたらfollowIDsだけが必要でfollowerIDsは消すことになるかもしれませんし、favoriteIDsにはどのコレクションについてのidかどうかという情報ものせる必要性があるかもしれません。

{
  _id:ObjectId(),//自動生成されるユニークキー
  username:,//ユーザーの名前を表示する時のもの
  exp:,//上の話でしていたLevel機能のためのもの
  stamina:,//Stamina機能を作るなら必要なので
  updateAt:,//一つ上のstaminaと合わせて必要
  email:,//メールアドレス
  password:hashing(),//ハッシュ化したパスワード
  followIDs:[],//followしたユーザーの_idの配列
  followerIDs:[],//followしてくれたユーザーの_idの配列
  favoriteIDs:[],//どれかのコレクションの_idの配列
  messageIDs:[],//投稿したmessageの_idの配列
  questIDs:[],//投稿したquestの_idの配列
  roomIDs : [],//参加しているroomの_idの配列
}

##Message collection
　messages collectionに保存するデータです。
　variableにとりあえず全部入れれば綺麗に見えるかもしれないと思ったのですけど、これは変えるかもしれません。変えないかもしれません。こうしてvariableにすべて入れると、quest collectionの方でも同じようなデータ構造にできるため、綺麗に見えなくもない。ただプログラムを書くときに少しめんどくさくなる。

{
  _id:ObjectId(),////自動生成されるユニークキー
  userid:,//メッセージを送信したユーザーの_id
  secret:,//secretはRoomの時だけ追加
  variable:{
    message:,//メッセージの内容
  },//何となくvariableの中に入れた
  address:{
    $ref:,//返信先のコレクション
    $id:,//返信先の_id
    $db:,//返信先のデータベース
  },//addressは返信の時だけ追加
  good:0,//goodを何度も押せる仕様なのでuseridは保持しない
  bad:0,//上と同じ
  favoriteIDs:[],//一度しか押せない仕様なのでuseridを配列で保持する
  IDs:[],//返信のmessageの_idを配列で保持する
}

##Quest collection
　quests collectionに保存するデータです。
　Questでは依頼を張り出して、依頼を受けた人と依頼をした人でRoomへと入るシステムを作りたいので、Roomについてのidを追加したいというのが今思い浮かぶ改善点ですね。

{
  _id:ObjectId(),//自動生成されるユニークキー
  userid:,//メッセージを送信したユーザーの_id
  variable:{
    title://Questのtitle
    message://Questの内容
  },//何となくvariableの中に入れた
  good:0,//goodを何度も押せる仕様なのでuseridは保持しない
  bad:0,//上と同じ
  favoriteIDs:[],//一度しか押せない仕様なのでuseridを配列で保持する
  IDs:[],//返信のmessageの_idを配列で保持する
}

##Room collection
　rooms collectioinに保存するデータです。
　複数人の人で話せる場を作る、Lineでいうグループです。もともとQuest用だけ作ろうと考えていたんですけど、それだったら別に普通のものを作るのは楽だったので、そのままの流れで作りました。

{
  _id:ObjectId(),//自動生成されるユニークキー
  title:,//Roomのタイトル
  admin:,//管理者としてのユーザー_id
  messageIDs:[],//会話した内容をmessageコレクションで保存するため、messageの_idの配列
  userIDs:[],//Roomに参加しているユーザーの_idの配列
}

#終わりに
　こういうデータベース関連の動作はpostで処理しており、プログラムを書くにはきちんとデータベースを触らないといけないけないなど、作業を他の人に任せるにはユーザーの権限とかファイルの権限とかを整えないといけないので少し時間がかかりますね。
　でもフロントエンドのプログラムだったらいろんな人と一緒にGuildシステムを作れるので、今後は依頼という形で仕事を人に頼んで、Guildシステムを作り上げたいと思います。