5
PostgreSQL：それぞれ1つのスキーマを持つ複数のデータベース、または複数のスキーマを持つ1つのデータベースを使用する方が良いですか？
私の質問の1つに対するこのコメントの後、Xスキーマを備えた1つのデータベースを使用する方が良いのか、またはその逆なのかを考えています。 私の状況：登録時にデータベースを（実際には）作成するWebアプリケーションを開発しています（いいえ、それはソーシャルネットワークではありません：誰もが自分のデータにアクセスできなければならず、他のユーザーのデータを見ることはありません）。 。 これが、以前のバージョンのアプリケーション（まだMySQLで実行されている）で使用した方法です。PleskAPIを使用して、すべての登録に対して、次のことを行います。 制限付きの権限を持つデータベースユーザーを作成します。 前に作成したユーザーとスーパーユーザーだけがアクセスできるデータベースを作成します（メンテナンス用） データベースに入力する 今、私はPostgreSQLでも同じことをする必要があります（プロジェクトは成熟し、MySQLになっています...すべてのニーズを満たすわけではありません）。 すべてのデータベース/スキーマのバックアップを独立させる必要があります。pg_dumpは両方の方法で完全に機能し、1つのスキーマまたは1つのデータベースのみにアクセスするように構成できるユーザーにとっても同じです。 それで、あなたが私よりも経験豊富なPostgreSQLユーザーであると仮定すると、私の状況に最適なソリューションは何だと思いますか、そしてその理由は？ $ xスキーマの代わりに$ xデータベースを使用するとパフォーマンスに違いがありますか？そして、どのソリューションが将来的に維持する方が良いでしょう（信頼性）？ すべてのデータベース/スキーマは常に同じ構造になります！ バックアップの問題（pg_dumpを使用）の場合、1つのデータベースと多くのスキーマを使用して、すべてのスキーマを一度にダンプする方が良いでしょう。回復は、開発マシンにメインダンプをロードして、必要なスキーマだけをダンプして復元することで非常に簡単です。これは1つの追加ステップですが、すべてのスキーマをダンプすると、1つずつダンプするよりも高速に見えます。 アップデート2012 さて、この2年間で、アプリケーションの構造とデザインは大きく変化しました。私はまだこのone db with many schemasアプローチを使用していますが、アプリケーションのバージョンごとに 1つのデータベースがあります。 Db myapp_01 \_ my_customer_foo_schema \_ my_customer_bar_schema Db myapp_02 \_ my_customer_foo_schema \_ my_customer_bar_schema バックアップについては、各データベースを定期的にダンプし、バックアップを開発サーバーに移動しています。 私はPITR / WALバックアップも使用していますが、前に述べたように、すべてのデータベースを一度に復元する必要はほとんどないので、おそらく今年は却下されます（私の状況では最善のアプローチではありません） ）。 アプリケーションの構造が完全に変更されていても、one-db-many-schemaアプローチは今から非常にうまく機能しました。 私はほとんど忘れてしまいました：すべてのデータベース/スキーマは常に同じ構造になります！ ...すべてのスキーマには、ユーザーのデータフローに応じて動的に変化する独自の構造があります。