データモデリング

[shu22203]

既存の設計をもとに改善点を洗う ただし、ユーザーデータ、スコアデータなどは過去のデータから移行できることが望ましい

↓既存のER図

[hidollara]

{before,after,total}_{start,end}ってなんですか？前後半全体それぞれの開始・終了日時とかですか？

[shu22203]

そうですー、主に前半期間中に後半の曲目が出ないように、後半終了〜結果発表日までランキングが隠される、といったことの制御に使われています

[hidollara]

こうしたいなぁみたいなものを書きました。 一応ざっくりと

• settings -> irs
• setting_models -> sections
• musics -> challenges
• music_details -> submission_types
• scores -> submissions

で、models、difficultiesは消してます。 ユーザーデータ、スコアデータは引き継げると思います。

意図を書いておくと

settingsの開始時刻周りがごっそり消えている

sectionごとに開始時間を管理すればいいと思っています。IR全体での開始/終了時刻は一番早いsectionの開始時間から一番遅いsectionの終了時間とかで管理できる気がしてます。

model（機種）がない / difficulties（難易度）がない

新しい機種の追加や細かい難易度設定をやりやすくするために、毎回定義した方が良いと思いました。

sectionやchallenge、submission_typeに毎回同じような入力をするのは面倒

DBに入れるよりも、jsonやyamlの形でテンプレートを用意する方が良いと思いました。

point関連

challngesに全て統合しました。

スコア枠/クリア枠の切り替え

コードレベルでカバーできると思っています。例えばクリア枠達成だけを提出として承認すれば、同率1位にmax_pointを割り振って、実質的にクリア枠として扱えると思います。

ir_admin_users

ユーザーが誰でもIRを開ける形にすれば色んな人が気軽にIRを立てられるんじゃないかなぁと思ってます。  [plantuml](http://www.plantuml.com/plantuml/uml/ZPBDRiCW3CVlF0NdIEq3J5NLqovxY8Y2crW34u6HLZLzzuMqf4kMJRdP_Ftni_4fiWgSd1Kj6f0QWxOWuYTIfu9oqY81NpkGFd3hXG1YvAjC4KAKDo5bXKQ-IKhk344U3WqG1CLWZiT1tEro12a7uZxbulPCHhOm636TYwc8V28DTO2OBDUAXo96yRn3hOn3gcUOzRpV-yVOgCenQzAhN0JDw6apDQxLAul8qxG-yDEkylxB2Da7Chy7qgso5gY1pGnFvlz1AgU-wiuZyUWWJGxvMVzX_mvZp0Nvscsd6BaR-8D2UpAOAGSnSa1g7gzmkQ16646u1H-0KIjRH-t3EjLceCKWcq-YI1F2uxBwVh_tjvyWGk3plRyjxb3CNNdtGr0lYrQofdCJnIZ2wmh4oopYyel4yc4DzWHaahFV)

[shu22203]

sections: なるほどー、機種ごとに期間を持つって感じか。入力の手間が増えたり日付のズレが起きやすそうというところが懸念かな

テンプレートで機種、難易度辺りの入力を楽にするのは良いアイデアっぽい、が曲によって4つ目の難易度があったりなかったり、あたりの微妙な差異が吸収できるかが分かっていない。

スコア枠、クリア枠が実質同じ扱いでうまくできるか、というところは確信が持てないな・・ 例えばクリア枠での同率である、というのをどう判断するかの材料がやや不自然なことをしないと出来ないはず。(スコアを必ず同じ値にするとか、submission_typesとJOINしてconditionがnullでない、とかで)

ユーザーが誰でもIRを開ける形にすれば色んな人が気軽にIRを立てられるんじゃないかなぁと思ってます。

これはとても 🙆‍♀️ サークルの盛り上がりにもつながってとても良いと思います！

[shu22203]

気になったところはこのへんかなー

[hidollara]

sections: (中略) 入力の手間が増えたり日付のズレが起きやすそう

これは絶対に前後半に分けるIRしか開催しないなら手間なんですが、気軽にIRを立てたりできるようになるとその制約が邪魔くさくなりそう…という気持ちでわざとバラした感じですね。 天才実装を思いつけばテンプレートに前後半の開始・終了日時を与えるとよしなに展開してくれる、みたいなやり方も出来ると思います。今は思いついていません。 日付のズレはなんかよく理解できてませんけど、人手で入力したら間違った日付入力しちゃうかも的なやつですかね？

曲によって4つ目の難易度があったりなかったり、あたりの微妙な差異が吸収できるか

これは無理に吸収しにいくんじゃなくて、人手で調整してもらう場所かなぁと思っています。

例えばクリア枠での同率である、というのをどう判断するかの材料がやや不自然なことをしないと出来ないはず。(スコアを必ず同じ値にするとか、conditionがnullでない、とかで)

そうですね、データとして残るスコアは必ず1にする、みたいな運用を頭の中で考えてました。 コードの中で動くときはそもそもスコアという値を内部には保持しないClearSubmissionみたいな型で、Submission interfaceにScore()みたいな関数を定義して、clearSubmission.Score()は常に1、みたいな実装で行けるんじゃないかなぁと思ってます。

[shu22203]

気軽にIRを立てたりできるようになるとその制約が邪魔くさくなりそう

これは確かにそうですね。実際選抜IRなんかは前後半無いので後半の期間をなくしたりとかで運用してもらってたのでうまくないやり方だなあとは思っていました

日付のズレ

これは後半を全部同じ日開始で設定していたつもりがある機種だけ1日ミスってて曲目先におちらしてしまうという事故が発生しそうだなという懸念ですね。 とはいえ自由度上げて細かく設定出来た方が発展性があると思うので、なんかミス多発して辛いとかにならない限りは、気をつけよう！でいいかなと思ってきた

無理に吸収しにいくんじゃなくて、人手で調整してもらう場所

なるほど、例えば難易度入れたら一旦その数だけ全部展開されるけど、その後要らない難易度のところは消せる、みたいなイメージかな。例えば。

データとして残るスコアは必ず1にする、みたいな運用

んー、というよりはクライアントサイド→サーバーに来た時点でそのsubmissionがclearのものというのをどう判別するんだろうが気になってるかな。 ユーザーにscore = 1と入れてもらう？ hidden parameterに1を入れる？←これはそのsubmission_typeがクリア枠だと知っていないと出来ないはず

[hidollara]

難易度入れたら一旦その数だけ全部展開されるけど、その後要らない難易度のところは消せる、みたいなイメージ

完全にその通りのイメージです！

クライアントサイド→サーバーに来た時点でそのsubmissionがclearのものというのをどう判別するんだろう

なんか落ち着いて考えてたら意外と面倒かも…となってます。 一応考えてたフローを書いておきますね。

まず、UIレベルでは明確に区別をしていいと思っています。 チェックボックスなりでクリア枠を設定すると理論値が設定できなくなり、内部的にはtheoretical_scoreに1でも入れておけばいいかなと。

クリア枠のsubmission_typeとつながってるsubmissionはscoreの設定無しでAPIにぶん投げても受理するようにしていいかなと（なぜならscoreを設定しても結局1になるだけなので）

提出はsubmission_typeとつながってるはずなので、サーバー側で内部的にsubmission_typeを引っ張ってきて、これのtheoretical_scoreが1だったら実装クラスがClearSubmissionになる…みたいな感じで復元できるものとしてました。

要するに、自分の主張としては「APIや実装レベルでは明確に区別してても、データベース上ではこれを意識して分割する必要ある？」ってところが根幹で、意識して分割しなくても行ける気がしたからまとめた、って感じです。

で、なにが面倒に感じたかって言うと、theoretical_score = 1が必ずしもクリア枠でしか使われないという保証が出来ない気がしたっていう感じです。なので、submission_typeにまんまScore/Clearみたいなもの持たせたほうがやっぱ楽かも…と思い直したってとこですね。

[shu22203]

なるほどなー、実現可能かでいえばYesであるがしかし、、というところだね。 なにより theoretical_score = 1 = クリア枠というのが暗黙知というかぱっと見わからない状態になるのはあんまりうまくないかなぁという感じではあるね

フラグ的に持つよりテーブル分けるのでもよさそう スコア枠にconditionなんて概念ないしね

[hidollara]

condition、結構広く解釈してて、難易度条件指定もクリア枠条件指定も等しくconditionに突っ込むかなぁとか思ってました difficultyとかの欄が消えたので、Plaintextで残しとくのがいいのかなぁとか思ってます

[hidollara]

submission_typeに紐付いたsubmissionを受理する条件、みたいなニュアンスですね

[junk0612]

あれ、ちょっとまって。condition って結局どんなのが入るの？

[hidollara]

僕が想像してたのだと、スコア枠のsubmission_typeなら"EXTREME 10.7", "ADVANCED 10.5", "BASIC 10.4"みたいなのが入って、クリア枠のsubmission_typeなら"冥 (ANOTHER) 4000点"とか入ります

[hidollara]

http://www.plantuml.com/plantuml/uml/bPF1Rl8m3CVlUOgSAy43V4A8qtVPGrGXDTHQObUE8mrHtdsbT1bKtTJT73ksVux_EIHreZa6qs83rgFu02Qz8tLENBG12VJIWMNHbeq1KjIBpGaasQknjiB6_hEKun74xdPd812dqEptGt2pkTyW5y7SIYwkprJK08EHyl7BT4ISoKCja7BGskbGf77wsg7kG2AcX4obMVtQx__RsAYwZx8S4WxFLHDuHQRLyBXKjho7jQbbqScknZMKOKONKBCudMzT241dM4qoaV-EKqNtKNUCfEC1gHo8N_eFovYUjfOSrbCKxXyuF5E3TyuXc5IGpWyld4xe4KOKRO455BqBTV8iorohaMQZ_5aX1U7n7_f-k-NhCuWnEFdxwqoMPgRI6m-N-iVFUiegiZEJKGBVEZ35BC7vaipSiGHx06fo39y0