注：これはMake WP Slackで行われた会話を元にしたものです（詳しい背景についてはリンクをご覧ください）。
サムネイルに関する現在の状況
サムネイルはプロバイダーによって収集され、カタログの thumbnail 列に格納されていました。現在もそこにはデータがあり、この列は削除されていません。また、この列はAPIにも存在するため、そこからのデータ（音声と画像の両方）がAPI側の thumbnail 列にもコピーされます。しかし、thumbnail 列を使用するのはAudioモデルだけであり、Imageモデルはこの列を無視し、元画像のURLを使って縮小版のサムネイルを作成しようとします。プロバイダー側のMediaStoreクラスは、新しいサムネイルURLが thumbnail 列に追加されないよう変更されていますが、メタデータの meta_data["thumbnail_url"] には追加できます。
最近、フルサイズの画像URLからサムネイルを作成しようとした際に、継続的なタイムアウトが発生し、レコードが検索結果に表示されなくなるケースがありました。SMKはその最近の例です：(1) (2)。このような場合には、プロバイダーが事前に生成したサムネイルを使用するのが有利かもしれません。重要なのは、すべてのプロバイダーがサムネイルを提供しているわけではなく、提供することを期待されているわけでもないということです。そのため、頻繁に空になるこの列を削除して、テーブルの横幅を縮小したいと考えるのがよさそうです。
提案
image については、まずカタログ内に既存するすべての thumbnail 値を meta_data["thumbnail_url"] にコピーします。次に、new-table-without-column-swap を実行し、テーブルから thumbnail 列を削除します。これにより、容量を節約し、テーブルの横幅を縮小できます。その後、 meta_data 辞書を使用してAPIAPI API（アプリケーション・プログラミング・インターフェース）とは、プログラム同士が相互に作用し、限定された明確な方法でデータを共有できるようにするソフトウェア仲介機能です。用の thumbnail 列を生成するよう、 image_view マテリアライズドビューを更新します。この例はAudioビューの audio_set_foreign_identifier にあります。これにより、APIでは thumbnail 列を維持しつつ、カタログ側の容量を削減できます。現時点では、API上でこのサイズの移行移行 Webサイトのコード、データベース、メディアファイルを、あるサーバーから別のサーバーへ移動すること。通常はホスティング会社を変更する際に行われます。を行うのはおそらく現実的ではないためです。続いて、両方の側のロジックに次の2つの変更を加えます：
ImageStoreにthumbnail_urlの処理ロジックを追加し、その値を自動的にmeta_data辞書に格納する- API側のImageモデルのロジックを変更し、まず
image.thumbnail（データ更新時にmeta_data["thumbnail_url"]からコピーされたもの）を使用し、次に縮小画像を作成する際にimage.urlを試す
Audioについても同じことができるかもしれません。レコードの約半数にはサムネイルがないようです：
deploy@localhost:openledger> select count(*) from audio where thumbnail is null;
+--------+
| count |
|--------|
| 427124 |
+--------+
SELECT 1
Time: 4.354s (4 seconds), executed in: 4.328s (4 seconds)
deploy@localhost:openledger> select count(*) from audio;
+--------+
| count |
|--------|
| 949384 |
+--------+
SELECT 1
Time: 3.899s (3 seconds), executed in: 3.887s (3 seconds)
このアプローチについて、皆さんはどう思いますか？DBテーブルの横幅を縮小するための取り組みは重要だと思います。将来的に、移行やデータ管理が容易になるからです。