自動ENUMのようなものはありますか？
文字列値を含む私が管理するいくつかのテーブルがあります（たとえば、4ワードの「タイプ」フィールド）。
DISTINCT文字列はごくわずかですが、- アプリケーションは、これまでに見たことのない新しい文字列を挿入する場合がありますが、
- アプリケーションの存続期間中、200を超える文字列が存在することはありません。つまり、システムはcouldこのフィールドを1バイトに格納します。
ディスク容量は問題ではありませんが、バイト数が少ないほど、ルックアップが高速になります。
私は、データベースエンジンがサポートしているとは思えないという考えを持っていますが、専門家に確認したいと思いました。
文字列は別のテーブルのIDにマップできます。そうすれば、プライマリテーブルのすべての行でこれらの文字列を繰り返す必要がなくなります。理想的には、データベースがこれを内部的に管理します。一意の文字列は、テーブル定義の一部として、目に見えない形で内部的に保存され、255未満の異なる可能性があるすべての文字列フィールドに対して、アプリを変更する必要がなく、システムはうまく機能します。
データベースエンジンにこのようなものはありますか？私は主にMySQLを使用していますが、アプリケーションを変更してカスタムラッパー関数を呼び出す以外に、これが実装されたことがあるかどうか知りたいです。 （INET_ATONと同様ですが、初めてIDを取得するためにAUTO_INCREMENTingテーブルに対してINSERTを透過的に実行する点が異なります）
何かが足りないかもしれませんが、抽象化レイヤーを提供するために、いくつかのビューを備えたこの種のことに対して、外部キー関係を持つルックアップテーブルを使用しないのはなぜですか？これは非常に一般的なアプローチであり、すべてのデータベースでサポートされており、実装が非常に簡単で、データの整合性などの他の問題（つまり、既存の文字列を含むテーブルのすべての行を更新せずに更新したい場合にどうなるか）を解決します。 ）。ルックアップテーブルのエントリの最大数がわかっている場合は、主キーのデータ量を最小化するデータ型を選択できます。また、将来、個別の値の数が最初に指定した制限を超える必要があると誰かが判断した場合、これははるかに簡単に処理できます。両方のテーブルの列のサイズを増やす必要があります。
ディスク容量は問題ではありません、
良い。
アプリケーションの存続期間中、200を超える文字列は存在しません。
有名な最後の言葉。私は負けるよりも勝つことが多いので、この種の要件に賭けることは常に幸せです。
これを処理する業界標準の方法は、個別のテーブル（ルックアップテーブルと呼ばれることが多い）とそれへの外部キー参照を使用することです。一部のデータベースプラットフォームはemunデータ型をサポートしていますが、メンテナンスに関してはルックアップテーブルより劣っているようです。列挙型を変更するには、テーブルの構造を変更する必要があります。ルックアップテーブルのデータを変更することは、行を変更することです。
ユーザーに文字列を提示する必要のあるアプリケーションコードは、ルックアップテーブルで文字列とそのID番号、またはコードを並べ替えられた順序でクエリし、結果セットをコンボボックスやリストボックスなどに読み込みます。自動的に更新されないキャッシュを使用している場合を除き、そのテーブルに追加された文字列は、後続のクエリに自動的に表示されます。
Oracleの Hybrid Columnar Compression などの列圧縮は、ルックアップを高速化するためにバイト数を減らすという目標を満たしています。また、説明する自動列挙型ほどではありませんが、ディスク容量を減らすという利点もあります。一方、200をはるかに超える個別の値を処理でき、アプリケーション側の変更は必要ありません。