enumデータ型を使用する代わりに新しいデータベーステーブルを作成するのは無駄ですか?
私が提供する4種類のサービスがあると仮定します(それらは頻繁に変わることはほとんどありません): テスト中 設計 プログラミング その他 上記のカテゴリのいずれかに該当する実際のサービスが60〜80個あるとします。たとえば、「サービス」は「テクニックAを使用したプログラムのテスト」で、タイプは「テスト」です。 それらをデータベースにエンコードしたいです。私はいくつかのオプションを思いつきました: オプション0: VARCHAR直接使用して、サービスタイプを文字列として直接エンコードします オプション1: データベースを使用しますenum。しかし、enumは悪です オプション2: 2つのテーブルを使用します。 service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 参照整合性も楽しむことができます: ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); いいですね。 しかし、私はまだ物事をエンコードし、整数を処理する必要があります。つまり、テーブルにデータを入力するときです。または、テーブルにデータを入力または処理するときに、手の込んだプログラミングまたはDB構造を作成する必要があります。つまり、データベースを直接扱うとき、またはプログラミング側で新しいオブジェクト指向エンティティを作成するときにJOINし、それらを正しく操作することを確認します。 オプション3: 使用しないでくださいenum。2つのテーブルを使用せず、整数列を使用してください。 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …