いくつかの値しか想定していないデータを扱わなければならないことがよくあります。OracleはVARCHAR2（16）（インデックスまたはテーブル）を保持するために16バイトを使用する必要があると思います。
FK を使用することもできますが、それは Oracle が別のテーブルに値が存在することを確認することを意味します。計算と RAM だけを使用することをお勧めします。しかも読みにくい。
その VARCHAR2(16) を数値または列挙型、または CHAR(1) に置き換えると、1 ～ 4 バイトが無駄になります。400 万行あると、スペースの無駄遣いを避けるのに役立つかもしれません。パフォーマンスに大きな影響を与える可能性がありますか?
また、インデックスの 4° の位置でフィールドを使用できるシナリオも想像します (これは選択的ではありません。使用するのはごくわずかだと思います)。
私の意見では、あなたは間違ったことを最適化しています。
テーブルに400万行があり、NUMBERまたはCHAR（1）フィールドを使用して、行ごとに平均10バイトのストレージを節約できたとします。これらのフィールドは、理解しにくいものの、使用するストレージが少なくて済みます。40メガバイト全体を節約できました！ウーフー!!! そして、その40メガバイトは、現在のストレージ価格では...まったく無関係です。
あなたはPENNIESで測定された節約について話している。誰かがあなたのENUM、CHAR（1）フィールドの意味、またはNUMBERフィールドの正しい解釈を理解するために費やす時間は、ドルで測定されます。たとえば、請負業者が圧縮フィールドを理解するのに1年に1分かかる場合（「うーん...「O」のステータスはオープン、または在庫切れを意味します...またはゼロです...そして、ゼロは再び何を意味するのでしょうか？」）、1時間あたり120ドルのコンサルティング料金で、ストレージに保存されたよりも多くの（2ドル）を圧縮フィールドの把握に費やしました。
あなたが提案していることは、ストレージが高価で豊富ではなかった1970年代（私がよく覚えている時代）に完全に理にかなっています-あなたは可能な限りすべてのバイトを節約し、フィールドを圧縮し、2桁の年を使用しました（覚えていますか？ :-)、そしてスペースを節約するためにあなたができるあらゆるトリックを使いました。今日、ストレージは安くて豊富です。TERABYTESで測定されたネットワークドライブを利用できます。比較的少量のストレージを節約するために開発者の時間を費やすのは、「結果の解釈に費やす時間」という点で無駄であり、その結果、「関係する時間に1ドルが費やされる」ことになります。物事をできるだけ明確に綴り、物事をできるだけ解釈しやすくします。YMMV。