1

現在、データベースの主キーを公開してパラメーターを選択する API を構築しています。私は pg_dump (およびそれに基づく Heroku pgbackups) が主キーをバックアップしていないように見えることを懸念しています。(毎回異なる順序で Postgres pg_dump ダンプ データベースを参照してください)

データベースをアップグレードするか、ステージングにコピーする必要がある場合は、Heroku フォロワーまたはフォーク機能を使用して主キーを保持できます。( https://devcenter.heroku.com/articles/heroku-postgres-follower-databasesおよびhttps://devcenter.heroku.com/articles/heroku-postgres-forkを参照)。ただし、開発で使用するためにデータベースをエクスポートすると、順序が失われます ( https://devcenter.heroku.com/articles/heroku-postgres-import-exportを参照)。

バックアップできない場合、データベース テーブルの ID を外部 API 識別子として使用するのは悪い考えですか?

各パラメーター テーブルに UUID 列を作成し、代わりにそれを公開することを検討する必要がありますか? ( http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.htmlを参照)

/v1/products?category=14,16&partner=3&q=plaid のような URL は開発者にとって作業しやすいと思いますが、移行が難しくなりすぎて Heroku に閉じ込められてしまうのではないかと心配しています。

ご提案いただきありがとうございます。

4

1 に答える 1

3

私は pg_dump (およびそれに基づく Heroku pgbackups) が主キーをバックアップしていないように見えることを懸念しています。

心配しないでください。もちろん、彼らはバックアップされます。それはリンクされたアイテムが言っていることではありません。

アイテムは、行がダンプされる順序が保証されていないと言っています。これは、(id=1, name="fred") が (id=1) を失うという意味ではなく、最初の項目として (バックアップ ファイルに) リストされていない可能性があるというだけです。投稿者が気にかけた唯一の理由は、バックアップ ファイルをテキストとして比較しようとしたからです。

于 2013-06-19T10:58:22.743 に答える