お経の句の順番(OkyoPhrase.order)の並び替えを管理するデータ構造について、以下のブログを参考に実装。
並べ替えできるデータをデータベースに保存する方法_zenn_Nakamura
方法1 (レコードに自身の順番を持たせる)と、方法6 (レコードの順序を配列として保存する)のどちらを実装するかについて順番のデータの更新における計算量や実装の容易さで、迷ったものの以下の点で方法１を採用。
- 順番データの更新/データ取得において、どちらも計算量は変わらない。新しい順番の更新の際も、方法6/方法1も配列/レコードから、挿入した順番から挿入する前の順番までの値を一つづつ、更新する必要がある。
- データの削除において、方法6(レコードの順序を配列として保存する)は、並び替えの順序を扱っている配列から、データ量だけ探索して削除する必要があるが、方法1は一つのデータ削除で済むことから、方法1の方が優位である
- 実装の容易性について、方法6(レコードの順序を配列として保存する)は、 配列を扱っており、RDBではレコードに配列型を扱うことは望ましいことではなく、とくに今回のお経のフレーズ（OKyoPrase)を配列の要素として管理するようにしてしまうと、以下のような２つの実装の手間が発生する。
- OkyoPraseを削除した場合に、順序を扱っている配列から、削除するOkyoPraseのIDを同時に削除しないといけない
- データを取り出す際に、順序を扱っている配列のお経フレーズのIDを、OkyoPraseのテーブルの所有するIDと結合する必要がある。
上記のように、RDBで配列型を扱う場合（とくに配列型に、その他のテーブルのIDを扱う場合）は、テーブルの結合に実装と計算時間の手間がかかる。また、方法6として、並び替えの順番が格納されている配列をKVS(キーバリューストア)で扱うことも考えられるが、並び替えの順番を扱う配列にその他のテーブル（お経フレーズ）のIDを扱うため、削除＆表示があった時に、テーブルの結合に時間がかかってしまう。また、方法6(レコードの順序を配列として保存する方法)は、別のテーブルを用意したりKVSなどの技術を使うため、方法1のレコードに自身の順番を持たせるだけの実装に比べて実装コストがかかってしまう。このことから、実装では方法6より方法1の方が、容易であると考えた。
音声や動画ファイルをアップロードする際に、 フロントエンド（Next.js）から直接アップロードするべきか、バックエンド(Rails)を経由してアップロードするべきかを検討する際に以下を参考にしました。