3

UTF8 エンコーディングと LC_* en_US.UTF8 の PostgreSQL データベースがあります。データベースには、テキスト列がさまざまな言語で格納されています。

ただし、一部の列では、特殊文字 (ISO 国コードや通貨コードなど) がまったく使用されないことを 100% 確信しています。

私は次のようなことを試みました：

"countryCode" char(3) CHARACTER SET "C" NOT NULL

と

 "countryCode" char(3) CHARACTER SET "SQL_ASCII" NOT NULL

しかし、これはエラーで戻ってきます

ERROR: type "pg_catalog.bpchar_C" does not exist
ERROR: type "pg_catalog.bpchar_SQL_ASCII" does not exist

私は何を間違っていますか？

さらに重要なことに、これを気にする必要がありますか? 私はこれを行うことがパフォーマンスとスペースの拡張であった MySQL のバックグラウンドから来ていますが、これは PostgreSQL にも当てはまりますか?

ティア

4

1 に答える 1

2

正直なところ、次のような設定の目的がわかりません。

  • @JoachimSauerが言及しているように、UTF-8エンコーディングのASCIIサブセットは、UTF-8を発明する主なポイントであったため、まったく同じバイト数を占有します。ASCIIを変更しないでください。したがって、サイズのメリットはありません。
  • 異なるエンコーディングの文字列を処理できるすべてのソフトウェアは、共通の内部エンコーディングを使用します。現在の PostgreSQL ではデフォルトで UTF-8 です。一部のテキストデータが処理段階に入ると、エンコーディングが一致しない場合、データベースはそれを内部エンコーディングに変換します。したがって、一部の列を非 UTF8 として指定すると、データの余分な処理が発生するため、いくつかのサイクルが失われます (ただし、パフォーマンスが大幅に低下するとは思わないでください)。

スペースの利点がなく、パフォーマンスが低下する可能性があることを考えると、そのままにしておく方がよいと思います。つまり、すべての列をデータベースのデフォルト エンコーディングのままにしておくことです。

同じ引数に対して、PostgreSQL はデータベース内の個々のオブジェクトのエンコーディングを指定することを許可していないと思います。文字セットとロケールは、データベース レベルごとに設定されます。

于 2012-06-28T12:19:29.893 に答える