Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2697 connectés 

  FORUM HardWare.fr
  Programmation
  Ruby/Rails

  Type enum, performance et maintenabilité

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Type enum, performance et maintenabilité

n°1738388
LeRiton
Posté le 28-05-2008 à 15:55:30  profilanswer
 

Bonjour,
 
Dans l'appli que je développe, un certain nombre de champs en base correspond à un type enum. Je tape sur une base Postgres en version 8.3 (qui gère donc le type). La situation ne devrait à priori pas changer à ce niveau, et si c'est le cas, MySQL serait certainement l'alternative, donc considérons que la base en question gère les enums.
 
J'ai tout d'abord regardé de ce côté. Beaucoup de code pour palier à un manque du langage, mais je crains surtout de gros problèmes de perfs.
 
L'autre solution serait d'appliquer un entier aux champs en question, avec une table d'association entier / intitulé en annexe. Pas génial en terme de maintenabilité.
 
Le plugin enum-column règle la question pour MySQL, mais je n'ai pas trouvé l'info concernant une éventuelle compatibilité avec Postgres depuis la gestion du type par le SGBD. Et quid du gain niveau perfs ?
 
Des avis sur tout ça ?
 
En question bonus : un type enum est cohérent pour un simple choix homme / femme (le booléen me déplait, toujours pour la lisibilité de la chose) ?

mood
Publicité
Posté le 28-05-2008 à 15:55:30  profilanswer
 

n°1739258
LeRiton
Posté le 30-05-2008 à 09:53:35  profilanswer
 

[:cerveau kunks] UP [:cerveau kunks]
 
Au moins pour des avis.

n°1739318
Paulp
~, sweet ~
Posté le 30-05-2008 à 11:17:50  profilanswer
 

LeRiton a écrit :

Bonjour,
 
Dans l'appli que je développe, un certain nombre de champs en base correspond à un type enum. Je tape sur une base Postgres en version 8.3 (qui gère donc le type). La situation ne devrait à priori pas changer à ce niveau, et si c'est le cas, MySQL serait certainement l'alternative, donc considérons que la base en question gère les enums.
 
J'ai tout d'abord regardé de ce côté. Beaucoup de code pour palier à un manque du langage, mais je crains surtout de gros problèmes de perfs.
 
L'autre solution serait d'appliquer un entier aux champs en question, avec une table d'association entier / intitulé en annexe. Pas génial en terme de maintenabilité.
 
Le plugin enum-column règle la question pour MySQL, mais je n'ai pas trouvé l'info concernant une éventuelle compatibilité avec Postgres depuis la gestion du type par le SGBD. Et quid du gain niveau perfs ?
 
Des avis sur tout ça ?
 
En question bonus : un type enum est cohérent pour un simple choix homme / femme (le booléen me déplait, toujours pour la lisibilité de la chose) ?


 
Peut-être avec des entiers et des constantes de classe du modèle
class Utilisateur << ActiveRecord::Base
  Utilisateur::Homme = 0
  Utilisateur::Femme = 1
end
Utilisateur.find_all_by_sexe(Utilisateur::Homme)
 
Comme ça, tu peux utiliser des booleens, ou des entiers de manière assez lisible ...
En plus, ça garde l'aspect triable des enums
 
J'ai jamais testé, mais ça devrait marcher, non ?

n°1740069
LeRiton
Posté le 02-06-2008 à 10:19:37  profilanswer
 

Salut à toi,
 
C'est ce que j'entendais par "L'autre solution serait d'appliquer un entier aux champs en question, avec une table d'association entier / intitulé en annexe.", bien que ce que tu me propose est de n'avoir d'"association" que dans le modèle.
 
Ce qui me dérange là dedans, c'est que la base et les migrations ne sont pas très "lisibles". Pas grave me diras-tu tant que le code l'est, mais c'est en ce sens que je venais prendre quelques avis.
 
On peut pas dire que le sujet déchaine les foules...

n°1740078
Paulp
~, sweet ~
Posté le 02-06-2008 à 10:27:13  profilanswer
 

LeRiton a écrit :

Salut à toi,
 
C'est ce que j'entendais par "L'autre solution serait d'appliquer un entier aux champs en question, avec une table d'association entier / intitulé en annexe.", bien que ce que tu me propose est de n'avoir d'"association" que dans le modèle.
 
Ce qui me dérange là dedans, c'est que la base et les migrations ne sont pas très "lisibles". Pas grave me diras-tu tant que le code l'est, mais c'est en ce sens que je venais prendre quelques avis.


 
En quoi les migrations perdent en lisibilité ?
Pour la lisibilité de la BDD, c'est sur, mais ça ne change pas beaucoup par rapport à une clé étrangère ...

LeRiton a écrit :


On peut pas dire que le sujet déchaine les foules...


C'est parce que Rails n'est utilisé que par l'élite  :o

n°1740088
LeRiton
Posté le 02-06-2008 à 10:40:46  profilanswer
 

Paulp a écrit :

En quoi les migrations perdent en lisibilité ?
Pour la lisibilité de la BDD, c'est sur, mais ça ne change pas beaucoup par rapport à une clé étrangère ...


 
Simplement que l'association intitulé / entier n'y apparaitra pas, donc on se saura pas à quoi correspondront les valeurs de  
 

Code :
  1. t.integer :gender


 
Ce qui est le but de l'enum.
 

Paulp a écrit :

C'est parce que Rails n'est utilisé que par l'élite  :o


 
L'auteur du topic ne saurait être tenu responsable, toussa...
 

n°1740455
Paulp
~, sweet ~
Posté le 02-06-2008 à 18:23:47  profilanswer
 

LeRiton a écrit :


 
Simplement que l'association intitulé / entier n'y apparaitra pas, donc on se saura pas à quoi correspondront les valeurs de  
 

Code :
  1. t.integer :gender


 
Ce qui est le but de l'enum.
 


 
Ah ouais, effectivement  :D


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Ruby/Rails

  Type enum, performance et maintenabilité

 

Sujets relatifs
Problème de traitement d'un input type sous IEUtiliser le Random pour un ENUM !!!!!!
[Résolu] MIME typeproblème balise input type text -->type File
Question pour page type .php?idErreur d'incompatibilité de type sur VBA
Vider le contenu d'un textarea en cochant un bouton de type "radio"Le formulaire n'envoie pas mes inputs type="file"
Autoriser un seul type dans un Edit 
Plus de sujets relatifs à : Type enum, performance et maintenabilité


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR