La première étape de la conception d'une base de données est de choisir les tables les plus adéquates possibles. Concrètement, une table est une collection de données qui doivent former un ensemble cohérent et sans répétition. Il est ainsi logique d'avoir dans une table 'dossier' des informations sur le nom du client, son prénom et sa date de naissance, car ces informations présentent une variabilité presque infinie (il y a des millions de noms différents par exemple si on prend l'échelle du monde).
Ce ne serait pas très malin en revanche de stocker le département de naissance du client en toutes lettres pour chaque client, puisque le nombre de départements est fini et très limité (cent), et a, à moins d'une prochaine restauration napoléonienne, très peu de chances d'augmenter. Faire ainsi induirait de lourdes répétitions dans la base. Une table d'association listant les départements fait en revanche très bien l'affaire, et seul l'id du département dans cette table d'association est inséré dans la table 'dossier'.
Le gain en terme de place est évident en évitant les répétitions. Un deuxième gain existe lors du parcours de la table : il est bien plus rapide pour MySQL d'analyser un nombre entier que de déchiffrer ligne après ligne une suite de lettres. Ce gain est encore plus visible avec l'utilisation des index (cf. un peu plus loin).
Ce principe de la non-répétition ou non-redondance des informations étant posé (on l'appelle « normalisation des données » dans l'intimité), sachez cependant être pragmatique, en dépit des ayatollah du modèle conceptuel de données intégristes. Si la duplication d'un ou deux champs d'une table à une autre vous permet de gagner 25% de temps d'accès aux données, alors cette architecture est raisonnée et justifiée. En revanche, dupliquer des champs un peu partout en base parce que vous n'aviez pas pensé qu'on pouvait faire autrement est plus difficilement justifiable, à moins d'invoquer un vent de paresse force 10 qu'il sera peut-être difficile de faire accepter à votre chef.