とは言ったもののキモチワルイｗ
アレだ。最初のフルバックアップの時のデータから何回かバックアップを取っているので
順次追っていけば良いんだよ。
と言葉で言うのは簡単でも、相手が4万レコード・5GBに近い重量級だと話が違ってくるｗ
ちょっと複雑な取得をしようとすると、めっちゃ待たされる。
テーブル構造がかなりイケてないしなぁ・・・。
ちなみに2.14の場合、
（例：日記）
c_diaryテーブルが日記本体
c_diaryのカラムにimage_filename_1～3があって、その中に画像ファイル名が格納される
c_imageテーブルが画像のバイナリデータ格納用
c_diaryと紐付けるのはfilename（＝画像ファイル名）※ここが非常に気持ち悪い
c_image_sizeにファイルサイズとかカテゴリを持っていて、それと紐付けるのもfilename
ああ、気持ち悪い。
これが3系になると
diaryテーブルが日記本体
画像を持っている日記はdiary_imageテーブルにレコードを持つ。紐付けはdiary_id
ファイルの付加情報はfileテーブルに持っていて、diary_imageとの紐付けはfile_id（fileテーブル側はid）
ファイルのバイナリデータはfile_binテーブルに持っていて、fileとの紐付けはfile_id
この構造だと気持ち悪くない。こうあるべきだと思う。
2系→3系の移行時に、レコードサイズがデカいからテーブルのコピーではなく
c_imageは移行後に残らないのでc_image→file_binに変更していると思われる。
つーか、コピーして使わなくなったテーブルをそのまま残すってのは迷惑なんだがｗ
話が大きく逸れた。
ひとまず一番最初に取ったバックアップ（2017年10月）をDB検証VMに突っ込んでみよう。
気になるのはc_imageとc_image_sizeのレコード数の差。
付加情報があるのにバイナリがない（その逆も）というのはオカシイ。数はイコールになるはず。
select count(*) from c_image; → 41649
select count(*) from c_image_size; → 41383
最初から合ってないよｗ(ﾉ∀`)
