メインコンテンツへスキップ

VillageSQL is a drop-in replacement for MySQL with extensions.

All examples on this page work on VillageSQL. Install Now →
データベースの中にないデータもあります。為替レート、配送状況、ジオロケーションの検索、サードパーティの製品詳細などです。標準的なアプローチは、アプリケーションコードでそれを取得し、テーブルにキャッシュするか、アプリケーション層でクエリ結果とつなぎ合わせることです。VillageSQL の vsql_http 拡張機能を使うと、そのデータをクエリから直接取り込んだり、1 回の UPDATE で列に保存したりできます。

セットアップ

パターン 1: 拡充データを列に保存する

最もよくある使い方は、外部 API から取得したデータで列をバックフィルすることです。行ごとに API を呼び出す UPDATE を実行し、結果を保存してから、保存した列をクエリします。 この例は、各注文の配送状況を取得します。
shipping_status IS NULL の行がなくなるまで、アプリケーションからこれをループで実行します。API のレート制限内に収まるよう、バッチで処理してください。 バックフィル後、クエリは保存された列を参照し、クエリごとの API 呼び出しはありません。

パターン 2: クエリ内でのライブ検索

為替レートやリアルタイム価格のように、変化が速すぎてキャッシュできないデータには、SELECT の中で API をインラインに呼び出せます。結果のすべての行がリクエストを発生させるため、結果セットは小さく保ってください。
共有する値は一度だけ変数に取得し、クエリではその変数を使います。各行が本当に異なる API 呼び出しを必要とするのでない限り、SELECT の式の中で http_get() を呼び出さないでください。

パターン 3: 条件付きの拡充

API を呼び出す前に WHERE でフィルタリングし、本当に必要な行に対してだけ取得します。
住所を url_encode() で包んでいる点に注意してください。ユーザーデータを URL に埋め込む前には、必ずエンコードします。

API エラーの処理

すべての vsql_http 関数は、接続失敗時に NULL を返し、curl のエラーメッセージを含む警告を出します。内容を使う前にステータスコードを確認してください。
一括 UPDATE のループでは、NULL または 200 以外のレスポンスを受け取った行は列の値が NULL のままになるため、UPDATE を再実行して失敗した行を再試行できます。

パフォーマンスに関する考慮事項

各 HTTP 呼び出しは同期的で、クエリをブロックします。 それぞれ 200ms の API にアクセスする 50 行のバッチは、最低でも 10 秒かかります。max_execution_time は SELECT ステートメントだけを制限し、ここでは効果がありません。この UPDATE の実行時間に上限を設けるには、事前に SELECT CONNECTION_ID() で接続 ID を取得しておき、長く走りすぎた場合に別のセッションから KILL QUERY <id> を実行します。
ライブでクエリするより結果を保存する方を優先してください。値が一度列に入れば、以降のクエリはネットワークに触れません。

トラブルシューティング

次のステップ

関連項目