episodes を animedb.yml から分離する

[builtinnya]

※ PR #45 がマージされてから取り組むこと

背景

ランダム文字列を識別子とする変更（issue #39，PR #45）に伴い，作品の基本情報以外のデータ（各話情報やスタッフ，キャラクターなど）を，識別子を用いて関連付けられるようになった（厳密にいえば変更前も識別名を用いて可能だったが，識別名には変更可能性が存在するため，難しかった）．
各話情報は既に一部のアニメについて入力されている（refs: #6，#10，#43）が，その数は作品よりオーダーが大きい．そのため，見通しが悪くなったり，スクリプトでの処理時間が余計に長くなったりして，編集作業に支障をきたしている．

問題

• 各話情報が膨大であり，編集作業の効率が低下している

解決方法案

スタッフやキャラクターなどのデータを将来的に追加することも見据えて，各話情報（episodes）を animedb.yml から分離する．つまり，各話情報は例えば episodes.yml ファイルに移される．
animedb.yml を animes.yml にファイル名を変更した方が命名的に一貫しているが，変更するかどうかは考えどころ．

episodes.yml の構造は以下のようになる．各話情報にも作品と同様に id を用意する予定．

Z5bwa8ArLg5: # 作品の id
  - id: mR22RyrHEuU # 各話情報そのものの id
    prefix: 第1話
    title: チビッ子魔女がやってきた No.1
    literal_title: 第1話 チビッ子魔女がやってきた No.1
    annict_id: 78126
  - ...

[eru]

書いてある分け方だと、結局episodes.ymlがかなり大きくなると思います。

現状、animedb.ymlが、751,688行あって、1作品あたりepisodesを除いて20行なので、
751688 - (20 * 10334) = 545,008行程度になるはずです。

また、episodes.ymlの成長スピードもかなり早く、週に60本以上放映しているため、
episodesの情報をフルに入力した場合7行あるので、60 * 7 = 420行以上毎週増えていくことになります。
※ 毎週入力できればですが。

結局、ランダム文字列のIDを付与した後に編集作業を行うとすると、

1. animes.ymlを、追加したい作品名で検索し、idを見つける
2. episodes.ymlを、idで検索し、追記箇所を見つける
3. episodes.ymlに追記する

という手順になるため、episodes/$id.ymlというように、
episodesディレクトリ下にanimes.idのyamlファイルを作っても手間は変わらず、
ファイルサイズを小さくできるのでいいのでは？

[builtinnya]

@eru
厳密に作業効率がどう変わるかを論じるのは難しいが，基本情報と各話情報を分けると，少なくとも基本情報については見通しが良くなる．
そのため，ファイル分割を前提とした上で，さらに各話情報の編集効率を上げるために，その「各話情報を作品ごとにファイルで分ける」という方式を提案していると解釈する．

その方式を採用すると，ファイルサイズは小さくなるが，当然ファイル数が多くなる．ファイル数が10^3〜10^4 オーダーになってくると，一つのディレクトリで管理することは難しい．
そうなると，年代・クールなどの基準によってさらにディレクトリを分けることになるだろうが，今度はプログラムでデータを扱うのが煩雑になってくる（どのディレクトリに該当ファイルが存在するかをシーケンシャルに確認する必要がある，etc.）

Linux カーネルでもファイル数は 53,647 個程度らしい（ref: 増え続けるLinuxカーネルコード、2016年第1四半期の総行数は2100万超 | マイナビニュース）．
Anime DB は今の段階では極少人数で管理すること，これからスタッフやキャラクターも追加することを考慮すると，その判断は少なくとも時期尚早であると思う．

[eru]

現状のanimedb.ymlファイルの編集も、エディタで編集していてファイルサイズが大きすぎて、問題が出るような状態ではないので、見通しの良さを求めて分割するのであれば、元の案でいいと思います。

仮に、episodesをディレクトリに分けて格納するという方法をとるのであれば、animes.idの頭2文字と使って、Z5bwa8ArLg5であれば、Z/5/Z5bwa8ArLg5.ymlなどにすれば、処理しやすくていいかも知れません。

ここまで書いて、いまさら気づいたのですが、ファイルシステムによっては、ファイル名の大文字・小文字を区別しないので、そこで衝突が起きる可能性があるため、提案した方法は難しいですね…

[builtinnya]

指摘の通り各話情報の増加頻度は非常に高いので，どこかの段階で episodes.yml を分割しなければならない．
将来的にファイル数を抑えて episodes.yml を分割する方法としては，例えば以下のやり方がある（細かいところはもっとベターなやり方があるだろう）．

• どこかの時点で，episodes2.yml などとして，別のファイルに各話情報の半分を移す
• episode-locations.yml ファイルを用意して，そのファイルに id からファイル名へのマッピングを書く

[builtinnya]

#46 (comment) の計算で行くと，週に420行増えるとして，作品の増加率を無視すると，1年で 21,840 行しか増えないのか．
episodes への大規模なマージ作業は基本的には過去の作品のみで完結するので，単純入力作業なら1ファイルで当分良さそう．