Structure de la base de données MySQL: plus de colonnes ou plus de lignes?

Question

Je crée un dictionnaire en ligne et je dois utiliser trois dictionnaires différents à cette fin: termes de tous les jours, termes chimiques, termes informatiques. J'ai des options d'arbres:

1) Créez trois tables différentes, une table pour chaque dictionnaire

2) Créer une table avec des colonnes supplémentaires, à savoir:

id term dic_1_definition dic_2_definition dic_3_definition 
---------------------------------------------------------------------- 
1  term1 definition 
---------------------------------------------------------------------- 
2  term2      definition 
---------------------------------------------------------------------- 
3  term3           definition 
---------------------------------------------------------------------- 
4  term4      definition 
---------------------------------------------------------------------- 
5  term5 definition        definition 
---------------------------------------------------------------------- 
etc. 

3) Créer une table avec un colonne supplémentaire « tag » et tag tous mes termes en fonction de c'est le dictionnaire, à savoir:

id term  definition tag 
------------------------------------ 
1  term1 definition dic_1 
2  term2 definition dic_2 
3  term3 definition dic_3 
4  term4 definition dic_2 
5  term1 definition dic_2 
etc. 

un terme peut être lié à un ou plusieurs dictionnaires, mais ont des définitions, disons un terme dans l'utilisation quotidienne peut différer du même terme dans le domaine informatique. C'est pourquoi on peut attribuer deux balises à term1 (dans ma dernière table) - dic_1 (id 1) et dic_2 (id 5).

À l'avenir, je vais ajouter plus de dictionnaires, donc il y aura probablement plus de trois dics. Je pense que si je vais utiliser l'option 2 (avec des colonnes supplémentaires), j'aurai à l'avenir une table et beaucoup de colonnes. Je ne sais pas si c'est mauvais pour la performance ou non.

Quelle est la meilleure approche dans mon cas? Lequel est le plus rapide? Pourquoi? Toutes les suggestions et autres options sont grandement appréciées.

Merci.

Answer 1

Je pense que vous devriez avoir une table de consultation pour vos types dictionnaire

DictionaryType (DTId, DTName)

Demandez à une table pour vous les termes

Conditions (Termid, termName) Puis vos définitions

Difinitions (DifinitionId, TermID, Définition, DTId)

Cela devrait fonctionner.

Answer 2

données .. Je Normalization aller avec 3, alors vous ne devez pas faire des questions de fantaisie pour identifier le nombre de définitions sont applicables par un terme

Answer 3

donné l'option 3 ressemble au choix le plus approprié pour votre scénario. Il rend les requêtes un peu plus simples et est définitivement plus facile à maintenir à long terme.

L'option 2 n'est certainement pas la bonne façon de procéder car vous allez vous retrouver avec beaucoup de valeurs nulles et écrire des requêtes sur une telle table sera un cauchemar.

L'option 1 n'est pas mauvaise mais avant que votre application puisse interroger, elle doit tromper la table à laquelle elle doit faire une requête et cela pourrait poser problème.

Donc, l'option 3 entraînerait des requêtes simples comme:

Select term, definition from table where tag = 'dic_1' 

Vous pouvez même créer une autre table tag pour garder les informations sur les balises elles-mêmes.

Answer 4

2) Créer une table avec colonne supplémentaire

Vous devriez certainement pas utiliser la 2ème approche. Et si à l'avenir vous décidez que vous voulez 10 dictionnaires? Vous devez créer un 10 colonnes supplémentaires qui est de la folie ..

Ce que vous devez faire est de créer une seule table pour tous vos dictionnaires et une seule table pour tous vos termes et une seule table Pour toutes vos définitions, toutes vos données sont regroupées de manière logique.

Ensuite, vous pouvez créer un ID unique pour chacun de vos dictionnaires, référencé dans la table des termes. Alors tout ce dont vous avez besoin est une simple requête pour obtenir les termes d'un dictionnaire particulier.

Answer 5

Il y a toujours un « ça dépend ... »

Cela dit, l'option 2 sera généralement un mauvais choix - tant du point de vue puriste (données Normaliser) et la perspective pratique - vous devez modifier la définition de la table pour ajouter un nouveau dictionnaire (ou en supprimer un ancien)

Si votre accès principal est toujours à la recherche d'un terme correspondant, et le nom du dictionnaire ('everyday', 'chemical', 'geek') est un attribut, alors l'option 3 a du sens. Si d'autre part, votre accès est toujours principalement par type de dictionnaire et par terme, et le dictionnaire 1 est énorme mais rarement utilisé, alors que les dictionnaires 2..n sont petits mais couramment utilisés, alors l'option 1 pourrait avoir plus de sens (ou option 1a => 1 table pour les dictionnaires rarement utilisés, une autre pour les dictionnaires fortement utilisés) ... c'est un cas très hypothétique!

Answer 6

Vous souhaitez extraire des données en fonction du type de dictionnaire, ce qui signifie que le type de dictionnaire est des données.

Les données doivent figurer dans les champs des tables, et non en tant que noms de table ou de champ. Si vous n'avez pas les données dans les champs, vous avez un modèle de données qui a besoin de modifications si les chances de données, et vous devez créer des requêtes de manière dynamique pour obtenir les données.

La première option utilise le type de dictionnaire comme noms de table.

La deuxième option utilise le type de dictionnaire comme noms de champ.

La troisième option place correctement le type de dictionnaire en tant que donnée dans un champ.

Cependant, le terme et la balise ne devraient pas être des chaînes, ils devraient plutôt être des clés étrangères aux tables où les termes et les types de dictionnaire sont définis.

Answer 7

J'ai développé un projet similaire et ma conception était la suivante. Stocker des mots, des définitions et des dictionnaires dans différentes tables est un choix flexible, en particulier lorsque vous allez ajouter de nouveaux dictionnaires à l'avenir.

alt text http://img300.imageshack.us/img300/6550/worddict.png

Answer 8

Votre structure de base de données devrait contenir données, la structure elle-même ne doit pas être données. Cela exclut l'option 2 immédiatement, sauf si vous créez les différentes tables afin de créer des applications distinctes s'exécutant sur les différents dictionnaires. Si elles sont partagées, alors c'est la mauvaise façon de le faire.

L'option 1 nécessite une modification de la base de données et les requêtes doivent être réécrites afin de permettre l'ajout de nouveaux dictionnaires. Il ajoute également une complication excessive aux requêtes simples, telles que "dans quels dictionnaires ce mot est-il?"

Option 3 Est le choix le plus flexible et le meilleur ici. Si vos données deviennent trop volumineuses, vous pouvez éventuellement utiliser les détails de la base de données comme le partitionnement de table pour accélérer les choses.

Answer 9

Les exigences sont ici trop vagues, ce qui entraîne une «réponse acceptée» totalement dépassée. Les exigences doivent fournir plus d'informations sur la façon dont les dictionnaires seront utilisés.

Cela dit, travailler le peu fourni; J'irais avec une variation sur # 3.

• Le numéro 1 est parfaitement viable si les dictionnaires sont utilisés de manière entièrement indépendante, et la seule raison pour laquelle le concept de termes partagés a été mentionné est qu'il s'agit d'une possibilité coïncidente.
• Ditch 2; il conduit inutilement à des valeurs NULL dans les colonnes, et les conceptions de DB n'aiment pas cela.
• Le numéro 3 est le meilleur, mais fossé la clé artificielle, et la clé sur Term + Tag. En dehors de la clé artificielle créant la possibilité d'entrées en double (par terme + tag). Si aucun autre tableau référence TermDefinitions, la clé est un gaspillage; si quelque chose le fait ils disent (par exemple) « Je fais référence TermDefinition # 3 ... Uhhm, quel qu'il soit. S »

En un mot, rien fourni à ce jour dans l'exigence indique une nécessité quoi que ce soit de plus compliqué que l'option 3.