Gestion des valeurs partitionnées et de leurs noms Enum (Java) vs DB

Lors du développement d'un système Il existe de nombreux cas où vous souhaitez faire correspondre la valeur de division avec sa signification, comme "1: homme, 2: femme", "A: excellent B: bon C: acceptable D: non". En outre, il existe de nombreux cas où vous souhaitez convertir une valeur de division en chaîne de caractères.

Donc, cette fois, je voudrais comparer la méthode utilisant Enum de Java et la méthode de sauvegarde dans la table maître de DB.

Il est supposé que Java sera utilisé comme langage et MySQL sera utilisé comme base de données.

1. Classe Enum

Dans Java5 et versions ultérieures, il existe le concept de type d'énumération. Effective Java recommande également de l'utiliser comme constante.

Tout d'abord, définissez l'interface d'encodeur suivante.

Interface codeur

/**
 *Interface d'encodeur pour Enum
 *
 * @param <T>Définition enum
 */
public interface Encodable<T extends Serializable> {
    /**
     *encodeur
     *
     * @return Enum définition
     */
    T getCode();

    /**
     *Renvoie le nom du code.
     *
     * @nom de retour
     */
    String getName();
}

Pour générer une chaîne à partir des valeurs d'indicateur, définissez la classe de décodeur comme suit:

Classe de décodeur

/**
 *Classe de décodeur pour Enum
 *
 * @param <K>Valeur de code
 * @param <V>valeur
 */
public class Decoder<K extends Serializable, V extends Encodable<K>> {

    /**Définition de la carte*/
    private Map<K, V> map;

    /**
     *Décodeur
     *
     * @valeurs de param groupe Enum
     */
    private Decoder(V[] values) {
        map = new HashMap<K, V>(values.length);

        for (V value : values) {
            V old = map.put(value.getCode(), value);

            //Ne prend pas en charge les valeurs de code en double
            if (old != null) {
                throw new IllegalArgumentException("duplicated code: " + value);
            }
        }
    }

    /**
     *Décodeur
     *
     * @valeur de code de code param
     * @retour classe Enum
     */
    public V decode(K code) {
        return map.get(code);
    }

    /**
     *Définition pour omettre la spécification de l'argument de type
     *
     * @param <L>Valeur de code
     * @param <W>valeur
     * @valeurs de param groupe Enum
     * @décodeur de retour
     */
    public static <L extends Serializable, W extends Encodable<L>> Decoder<L, W> create(W[] values) {
        return new Decoder<L, W>(values);
    }
}

La classe réelle ressemble à ceci: Dans le cas du genre, ce sera comme suit.

Classe d'énumération de genre

/**
 *Classe d'énumération de genre.
 * 
 */
public enum Gender implements
                     Encodable<Integer> {

    /**Homme*/
    MALE(1, "Homme"),
    /**femme*/
    FEMALE(2, "femme");

    /**Décodeur*/
    private static final Decoder<Integer, Gender> DECODER = Decoder.create(values());

    /**Valeur de code*/
    private final Integer code;

    /**Nom*/
    private final String name;

    /**
     *constructeur.
     * 
     * @valeur de code de code param
     * @nom du paramètre nom
     */
    private Gender(Integer code, String name) {
        this.code = code;
        this.name = name;
    }

    @Override
    public Integer getCode() {
        return code;
    }

    /**
     *Obtenir la classe Enum à partir de la valeur de code.
     * 
     * @valeur de code de code param
     * @return Format de réception Classe Enum
     */
    public static Gender decode(Integer code) {
        return DECODER.decode(code);
    }

    /**
     *Méthode pour obtenir le nom.
     * 
     * @nom de retour
     */
    public String getName() {
        return name;
    }
}

Vous pouvez obtenir le nom avec la classe decode et la méthode getName comme indiqué ci-dessous.

Exemple d'utilisation

// 1:Masculin
Gender male = Gender.decode(1);
String name = male.getName();

mérite

Maintenabilité élevée

Si vous l'écrivez dans le programme et lui donnez un nom de classe significatif, il sera hautement lisible et maintenable. Le code est facile à maintenir.

Logique facile à écrire

Il est facile à traiter car vous pouvez obtenir le nom de la division sans vous connecter à la base de données un par un.

Démérite

Il n'est pas facile d'ajouter une valeur de division ou de changer le nom

Lorsqu'une valeur de division est ajoutée ou qu'un nom est changé en raison d'un changement de spécification, etc., une modification du programme se produira et un travail de publication se produira également.

Quand utiliser

Je pense que c'est une bonne idée d'utiliser Enum pour gérer des choses qui ne peuvent pas être changées, comme le genre et les préfectures au Japon. Si ça change, je pense qu'il est souvent nécessaire de modifier la logique.

2. Table maître DB

C'est comme gérer l'identifiant et son nom à l'aide de la table maître suivante. Bien entendu, il est possible de saisir des informations supplémentaires en plus du nom.

Maître des utilisateurs de connexion

CREATE TABLE login_user_mst (
    id VARCHAR(11) NOT NULL,
    password CHAR(40) NOT NULL comment 'Mot de passe',
    name VARCHAR(255) NOT NULL comment 'Nom complet',
    name_kana VARCHAR(255) default NULL comment 'Nom Kana',

    PRIMARY KEY(id)
) CHARACTER SET 'utf8'
  COMMENT 'Utilisateur de connexion';

Exemple de données

mérite

Facile à changer le nom

Pour changer le nom de la valeur de la partition, mettez simplement à jour l'enregistrement DB, donc Le coût est assez bas car il peut être changé sans aucune modification du programme.

Vous pouvez obtenir le nom de la division par jointure de table

Puisque vous pouvez rejoindre la table maître et obtenir le nom uniquement avec SQL, Tout ce dont vous avez besoin est la logique d'affichage du résultat SQL à l'écran ou de sa sortie au format CSV.

Démérite

Le traitement des succursales par valeur de division n'a pas de sens

Par exemple, lorsqu'une branche de processus se produit en fonction de la valeur de division, Parce qu'il n'y a pas d'autre choix que d'avoir cette valeur de classification du côté de l'application Même si vous avez une valeur dans la base de données, elle sera dans un état de double maintenance.

Difficile à gérer car le nombre de tables augmente

Si le projet a une règle qui "gérons toutes les constantes de la table maître", Lorsqu'il existe de nombreux types de constantes, si vous créez une table pour chaque constante, un grand nombre de tables maîtres seront créées. S'il s'agit d'une table maître, je pense qu'il est toujours facile de gérer s'il existe une règle telle que le préfixer avec "mst_". ..

Quand utiliser

Gestion des utilisateurs connectés, informations du bureau de vente, Je pense qu'il est bon de l'utiliser pour des choses qui sont relativement modifiées dans de nombreux cas.

À la fin

Je pense que la façon de gérer la valeur de la division et le nom est un problème éternel (personnellement). Dans mon projet actuel, j'utilise à la fois le type Enum et le maître DB. Je pense que vous devez comprendre et utiliser chaque caractéristique.