整数は4バイトを占めることになります。これは、「vw」よりも1バイト多くなります。たまたま、PostgreSQLの列挙型も4バイトを占めるため、この表現に切り替えることでストレージに関して何も得られません(列挙型自体の変更に課せられる問題を除いて)。そのサイズのテーブルを使用すると、とにかくインデックスを参照するため、クエリはどちらの方法でも同じように高速になります。データベースのパフォーマンスは、特にテーブルが大きくなる場合、基本的にI / Oの問題であり、CPUのパフォーマンスではありません。整数のインデックスが短い文字列のインデックスよりも小さくなったり速くなったりすることは確信できません。特に、可能な値の非常に小さなセットを参照する行が大量にある場合はそうです。それは確かにあなたのアプリケーションのボトルネックになることはありません。
人工キーを使用して4バイトを回復できたと仮定しても、どのくらいのストレージを節約できますか?4バイト×1億行は、理想的には約400MBになります。honkinのデータベースサーバーで、そのような少量を探す必要があるほどストレージを求められていますか?そしてこれは、それを独自のテーブルにリファクタリングし、適切な外部キーを使用することを前提としています。
もちろん、これに答える正しい方法は、第一原理からまったく議論しないことです。1億行のテーブルを取得し、両方の方法で実行します。次に、次のように自分でサイズを調べます。
SELECT pg_size_pretty(pg_total_relation_size('ownership')));
SELECT pg_size_pretty(pg_total_relation_size('ownership2')));
EXPLAIN ANALYZEを使用して、次のようにテストクエリを実行します。
EXPLAIN ANALYZE SELECT * FROM ownership WHERE car = 'audi';
EXPLAIN ANALYZE SELECT * FROM ownership2 WHERE car_id = 1;
コストよりも実際にかかる時間に注意を払いますが、コストを確認してください。可能であれば、本番環境と同じデータベースサーバーでこれを実行します。そうでない場合は、同じPostgreSQL構成の同様のマシン。そうすれば、あなたはあなたが何にお金を払って何を得ているのかをあなたに伝えるための難しい数字を持っているでしょう。私の疑惑は、人工キーと同等のパフォーマンスを使用すると、スペースの使用量がわずかに悪化することに気付くでしょう。
それがわかった場合は、リレーショナルを実行して自然キーを使用し、物理ストレージの最適化についてそれほど心配する必要はありません。スペースはあなたが持っている最も安い商品です。