Single Large v/s Plusieurs petites tables MySQL pour stocker les options

Question

Je suis conscient de plusieurs questions sur ce forum à ce sujet. Supposons que j'ai une énorme table d'options qui stocke des options de liste comme le genre, l'état matrimonial, et bien d'autres groupes spécifiques au domaine ayant la même structure. Je prévois de capturer dans un tableau OPTIONS. Une autre option simple est d'avoir le champ défini comme ENUM, mais il y a aussi des inconvénients. http://www.brandonsavage.net/why-you-should-replace-enum-with-something-else/

OPTIONS Tableau:

option_id <will be referred instead of the name> 
name 
value <more like a description, and not a name/value pair> 
group 

Requête: select .. from options where group = '15'

Utilisation: Sexe & Marital_Status sera dans les tableaux Personnes; mais la valeur stockée proviendra des options

eg. 
    Person 
    .. 
    id=34 name=Prasad gender=31 marital_status=41 
    .. 

    Options 
    .. 
    31 gender male male 
    32 gender female female 
    ... 
    41 marital_status single single 
    42 marital_status married married 
    .. 

• Comme ce tableau devrait être multi-locataire, le pas de lignes pourrait croître de façon drastique.
• Je crois que scinder les tables au lieu de trouver par le groupe serait plus facile à écrire & plus rapidement à exécuter.
• ou peut-être le partitionnement par le groupe ou le locataire?

Answer 1

Il s'agit essentiellement d'un EAV model, avec tous les avantages et les inconvénients qui y sont associés. Un modèle EAV est utilisé dans des circonstances où le nombre d'attributs (propriétés, paramètres) pouvant être utilisés pour décrire une chose (une «entité» ou un «objet») est potentiellement vaste, mais le nombre qui s'applique réellement à une entité donnée est relativement modeste. Il est également connu comme une «matrice clairsemée».

Un bon exemple d'utilisation appropriée pour une table EAV est les symptômes dans une base de données médicale. Bien qu'il existe potentiellement des milliers de symptômes possibles, la personne moyenne se rendant chez le médecin ne présentera qu'un nombre beaucoup plus faible de symptômes.

Le Wikipedia article about EAV devrait vous indiquer si ce modèle est approprié pour votre application particulière, et suggérer quelques bonnes pratiques à cet égard. Notez que si vos colonnes d'exemple sont Sexe et État civil, et que vous avez une table Personnes, ces colonnes appartiennent de manière plus appropriée à la table Personnes, et non à une table EAV.

Answer 2

Le système sur lequel je travaille a ce problème précis. C'est dans le domaine des soins de santé.

Nous avons quelques tables de codes normalisées, comme le sexe (évident) et l'état du patient (patient hospitalisé, ambulatoire, urgence, observation, préopératoire). Nous traitons chacun d'eux comme une petite table séparée. Ces tables, étant minuscules et d'un contenu relativement statique, ne nécessitent pas beaucoup de maintenance. Donc, dans ces cas-là, nous acceptons l'efficacité de réduire la taille des tables et de payer le coût d'une variété d'entre elles. Mais nous avons aussi des tables dont les valeurs nous sont fournies par nos clients hospitaliers, telles que la religion, la relation de parenté (fille, père, etc.). Nous traitons également les diagnostics dans ce tableau, parce que les hôpitaux ont différentes façons de coder ces choses, et ils sont en constante expansion.* Ces tables reçoivent régulièrement de nouvelles valeurs lorsque nous ajoutons de nouveaux clients hospitaliers à notre système, et lorsque ces hôpitaux rencontrent de nouveaux problèmes. Les valeurs de ces tableaux et les types de tableaux que nous devons conserver reflètent la diversité de la vie humaine et le fait que nos clients hospitaliers découvrent souvent de nouvelles choses au sujet de leurs patients. Dans ce cas, il est logique de conserver tous ces codes dans une seule table de référence. Chaque entrée a un identifiant. Nous attribuons également un identifiant client et un type de code (par exemple religion, diagnostic), un nom de code (par exemple, PROT, CATH, BUDD) et une valeur de code (par exemple, protestant, catholique, bouddhiste). Enfin, nous ajoutons une priorité, ce qui nous permet de contrôler l'ordre des listes de sélection dans notre application.

Dans ce cas, l'efficacité d'une seule grande table est compensée par le fait que nous pouvons avoir une base de code pour maintenir cette table et une interface utilisateur unifiée. NE PAS mettre les noms des personnes, ou toute autre information potentiellement confidentielle, dans cette table de code, sauf si vous voulez faire face à un problème de sécurité complexe sous beaucoup de pression dans le futur. Si vous travaillez dans le domaine de la santé, il vaut mieux savoir ce que vous ferez des codes de diagnostic CIM-9 et CIM-10. Un basculement est à venir, et ce ne sera pas facile.

Bonne chance