0

PHP（Symfony 2）とPostgreSQLでWebアプリケーションの新しいプロジェクト（完全な再起動）を作成することを計画しています。現在、PHPとMySQL（MyISAM）を使用しています。-> webapp

現在および新しいWebアプリケーションは、データベース（MS SQL 8/2000）を含む別のシステム（.NET）に依存しています。これは、メギッラー全体で複雑なワークフローがあるため、すぐに変更（データベースを変更またはマージ）することはありません。 ->レガシーシステム
ところで：最大のテーブルには合計2700万行あります

ほとんどのデータ/テーブルは、レガシーデータベースからwebappデータベースに1日に複数回転送されます。新しいWebアプリでは、データベーススキーマのほとんどをすでに再設計したため、ほぼ正規化されたスキーマになりました（レガシーデータベースのスキーマは非常に冗長で、非常に面倒です）

現在、転送ジョブはデータを挿入しようとしています。特定のコードで例外が発生した場合、その行はすでに存在していることがわかり、更新を実行します。これはパフォーマンスによるものです（更新前に選択しない）。

新しいWebアプリケーションスキーマでは、従来のデータベースと同じプライマリIDを使用する必要があります。しかし、いくつかの問題があります。そのうちの1つは、整数のように見える主キーを持つテーブルもありますが、そうではありません。ほとんどの行には、のような整数が123456ありますが、。のような文字を持つ行もあります123456P32。

新しいスキーマには2つのオプションがあります。

  1. PKとリスクパフォ​​ーマンスの問題に文字列型を使用する

  2. PKに整数型を使用して変換を行う変換は次のようになります（文字ベース）

    legacy      new
--------------------------
0           10
1           11
2           12
.           ..
9           19
a           20
b           21
.           ..
y           45    
z           46
A           50 (not 47, because the arity of the second digit is 'clean' with 50)
B           51
.           ..
Z           76

従来のpk123は111213に変換されるため、長さは元の長さの2倍になります。別の例123A9- > 1112135019。すべての文字は2桁であるため、元に戻すこともできます。

私の最初の疑問は、スパースPKがパフォーマンスの問題を引き起こすことでしたが、Postgresのデフォルトのインデックスシステムであるインデックスとしてb-tree（セルフバランシング）を使用する場合は問題ありません。

どう思いますか？従来の依存関係を持つ同様のシステムの経験はありますか？

4

2 に答える 2

1

提案されたデータ型を分離するには、CREATE DOMAIN を使用します。次に、プロトタイプを作成してテストします。幸運ですね; 有効なテスト データが不足することはありません。

create domain legacy_key as varchar(15) not null;

create table your_first_table (
  new_key_name legacy_key primary key,
  -- other columns go here.
);

整数キーを使用して 2 番目のデータベースをテストするには、スキーマをダンプし、その 1 行 (および両方を同時に使用する場合はデータベースの名前) を変更し、リロードします。

create domain legacy_key as bigint not null;

レガシ システムの主キーをそのまま正確に保存することについては、十分に検討する必要があります。デバッグする必要はありません。大きな安心です。変換する必要がある場合は、「1234P45」などの値に注意してください。その文字がたまたまEまたはDである場合、一部のアプリケーションはそれを指数を示すものとして解釈します。

特にバージョン 9.2 では、10 文字または 15 文字の varchar() キーを使用している場合、キーの長さが原因でパフォーマンスの問題が発生することはありません。開始する前に、インデックスに関するドキュメントをお読みください。PostgreSQL は、ほとんどの人が認識しているよりも多くの種類のインデックスをサポートしています。

于 2012-10-25T16:11:04.277 に答える
1

  • テキスト PK を使用した PostgreSQL のパフォーマンスはそれほど悪くありません。単純にするために、私はそれを使用します。

  • これらのキーの長さを教えてくれませんでした。変換を使用すると、通常の整数は 4 文字のキーのみに、bigint は 9 のみに十分です。

于 2012-10-25T15:54:59.530 に答える