186

私の質問の 1 つに対するこのコメントの後、X スキーマで 1 つのデータベースを使用する方が良いか、またはその逆かを考えています。

私は、人々が登録するときに (実際には) データベースを作成する Web アプリケーションを開発しています (いいえ、それはソーシャル ネットワークではありません。誰もが自分のデータにアクセスでき、他のユーザーのデータを見ることはありません)。これは、以前のバージョンのアプリケーション (まだ MySQL で実行されている) で使用した方法です。登録ごとに、Plesk API を使用して、次のことを行います。

  1. 権限が制限されたデータベース ユーザーを作成します。
  2. 前回作成したユーザーとスーパーユーザーだけがアクセスできるデータベースを作成する（メンテナンス用）
  3. データベースにデータを入力する

今度は、PostgreSQL で同じことを行う必要があります (プロジェクトは成熟しつつあり、MySQL はすべてのニーズを満たしていません)。すべてのデータベース/スキーマのバックアップを独立させる必要があります。pg_dump両方の方法で完全に機能し、1 つのスキーマまたは 1 つのデータベースのみにアクセスするように構成できるユーザーに対しても同じです。

では、あなたが私よりも経験豊富な PostgreSQL ユーザーであると仮定すると、私の状況に最適なソリューションは何だと思いますか? またその理由は? $x スキーマの代わりに $x データベースを使用すると、パフォーマンスに違いはありますか? また、将来維持するのに適したソリューションはどれですか (信頼性)? すべてのデータベース/スキーマは常に同じ構造になります!

バックアップの問題 (pg_dump を使用) については、1 つのデータベースと多くのスキーマを使用して、すべてのスキーマを一度にダンプする方がよいかもしれません: 回復は非常に簡単で、メイン ダンプを開発マシンにロードしてから、必要なスキーマだけをダンプして復元します。は 1 つの追加ステップですが、すべてのスキーマをダンプする方が、1 つずつダンプするよりも高速に思えます。

2012年更新

アプリケーションの構造とデザインは、この 2 年間で大きく変化しました。私はまだ「多くのスキーマを持つ1つのデータベース」アプローチを使用していますが、それでも、アプリケーションのバージョンごとに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 バックアップも使用していますが、前に述べたように、すべてのデータベースを一度に復元する必要はほとんどありません。したがって、今年はおそらく却下されるでしょう（私の状況では、最善のアプローチではありません）。

アプリケーション構造が完全に変更されたとしても、1 db 多スキーマ アプローチは今では非常にうまく機能しています。私はほとんど忘れていました: すべてのデータベース/スキーマは常に同じ構造を持ちます! 現在、すべてのスキーマには独自の構造があり、ユーザーのデータ フローに動的に反応して変化します。

4

7 に答える 7

163

PostgreSQL の「スキーマ」は、MySQL の「データベース」とほぼ同じです。PostgreSQL インストールに多くのデータベースがあると、問題が発生する可能性があります。多くのスキーマを持っていても問題なく動作します。したがって、1 つのデータベースとそのデータベース内の複数のスキーマを使用することは間違いありません。

于 2009-07-21T02:25:46.410 に答える
34

間違いなく、1 db 多スキーマのアプローチを採用します。これにより、すべてのデータベースをダンプできますが、多くの方法で非常に簡単に 1 つだけを復元できます。

  1. データベース（すべてのスキーマ）をダンプし、ダンプを新しいデータベースにロードし、必要なスキーマだけをダンプして、メインのデータベースに復元します。
  2. スキーマを 1 つずつ個別にダンプします (ただし、マシンはこの方法でさらに苦しむと思います - そして、500 のスキーマを期待しています!)

それ以外の場合、グーグルで検索すると、スキーマを複製する自動手順がないことがわかりました（テンプレートとして使用）が、多くの人がこの方法を提案しています：

  1. テンプレート スキーマを作成する
  2. 複製する必要がある場合は、新しい名前で名前を変更します
  3. それを捨てなさい
  4. 名前を元に戻します
  5. ダンプを復元する
  6. 魔法が完成しました。

そのために Python で 2 つの行を書きました。彼らが誰かを助けることができることを願っています（2秒で書かれたコード、本番環境では使用しないでください）：

import os
import sys
import pg

# Take the new schema name from the second cmd arguments (the first is the filename)
newSchema = sys.argv[1]

# Temperary folder for the dumps
dumpFile = '/test/dumps/' + str(newSchema) + '.sql'

# Settings
db_name = 'db_name'
db_user = 'db_user'
db_pass = 'db_pass'
schema_as_template = 'schema_name'

# Connection
pgConnect = pg.connect(dbname= db_name, host='localhost', user= db_user, passwd= db_pass)

# Rename schema with the new name
pgConnect.query("ALTER SCHEMA " + schema_as_template + " RENAME TO " + str(newSchema))

# Dump it
command = 'export PGPASSWORD="' + db_pass + '" && pg_dump -U ' + db_user + ' -n ' + str(newSchema) + ' ' + db_name + ' > ' + dumpFile
os.system(command)

# Rename back with its default name
pgConnect.query("ALTER SCHEMA " + str(newSchema) + " RENAME TO " + schema_as_template)

# Restore the previous dump to create the new schema
restore = 'export PGPASSWORD="' + db_pass + '" && psql -U ' + db_user + ' -d ' + db_name + ' < ' + dumpFile
os.system(restore)

# Want to delete the dump file?
os.remove(dumpFile)

# Close connection
pgConnect.close()
于 2009-07-21T06:21:05.893 に答える
18

私は、複数のデータベースと複数のスキーマを使用すると言います:)

PostgreSQL のスキーマは、Oracle のパッケージによく似ています。データベースはデータ セット全体を区別することを目的としていますが、スキーマはデータ エンティティに似ています。

たとえば、スキーマ「UserManagement」、「LongTermStorage」などを使用して、アプリケーション全体に対して 1 つのデータベースを作成できます。「UserManagement」には、「User」テーブルと、ユーザー管理に必要なすべてのストアド プロシージャ、トリガー、シーケンスなどが含まれます。

データベースはプログラム全体であり、スキーマはコンポーネントです。

于 2009-07-20T14:09:09.100 に答える
5

これを確認する参照は見つかりませんが、多くのスキーマは多くのデータベースよりも軽量である必要があります。

しかし、(「顧客」列がテーブルに追加されるように Web アプリケーションをリファクタリングするのではなく) 物事を非常に分離したい場合でも、別のデータベースを使用することをお勧めします:他の顧客を邪魔することなく、特定の顧客のデータベースをこの方法で。

于 2009-07-20T20:42:02.517 に答える