Que vous travailliez avec une base de données contenant des centaines d'enregistrements ou des millions d'enregistrements, une conception de base de données appropriée est toujours importante. Cela facilitera non seulement l'extraction des informations, mais facilitera également l'expansion future de la base de données. Malheureusement, il est facile de tomber dans quelques pièges qui peuvent rendre les choses difficiles à l'avenir.
Des livres entiers ont été écrits sur la normalisation d'une base de données, mais si vous évitez simplement les erreurs courantes montrées ici, vous serez sur la bonne voie pour une bonne conception de base de données.
Erreur de base de données n ° 1: Répétition de champs dans une table
Une bonne base de données pour bien concevoir une base de données est de reconnaître les données répétitives et de placer ces colonnes dans leur propre tableau. La répétition de champs dans un tableau est courante pour ceux qui viennent du monde des feuilles de calcul, mais si les feuilles de calcul ont tendance à être plates par nature, les bases de données doivent être relationnelles. C'est comme aller de la 2D à la 3D.
Heureusement, les champs répétitifs sont généralement faciles à repérer. Jetez un coup d'œil à cette table:
| Numéro de commande | Produit1 | Produit2 | Produit3 |
| 1 | Nounours | Jelly Beans | |
| 2 | Jelly Beans |
Que se passe-t-il lorsqu'une commande contient quatre produits? Nous aurions besoin d'ajouter un autre champ à la table pour prendre en charge plus de trois produits. Et si nous avons créé une application client autour de la table pour nous aider à saisir des données, il se peut que nous devions la modifier avec le nouveau champ de produit. Et comment trouver toutes les commandes avec Jellybeans dans la commande? Nous serions obligés d'interroger chaque champ de produit de la table avec une instruction SQL qui pourrait ressembler à: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OU Product2 = 'Jelly Beans' OU Product3 = 'Jelly Beans'.
Au lieu d'avoir un seul tableau qui rassemble toutes les informations, nous devrions avoir trois tableaux contenant chacun un élément d'information distinct. Dans cet exemple, nous voudrions une table de commandes contenant des informations sur la commande elle-même, une table de produits contenant tous nos produits et une tablette ProductOrders liant les produits à la commande.
| Numéro de commande | N ° de client | Date de commande | Total |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| ID de produit | Produit | Compter |
| 1 | Nounours | 1 |
| 2 | Jelly Beans | 100 |
| ProductOrderID | ID de produit | Numéro de commande |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Notez que chaque table a son propre champ ID unique. C'est la clé primaire. Nous lions des tables en utilisant une valeur de clé primaire en tant que clé étrangère dans une autre table. En savoir plus sur les clés primaires et les clés étrangères.
Erreur de base de données n ° 2: incorporation d'une table dans une table
C'est une autre erreur courante, mais elle ne se distingue pas toujours autant que les champs répétitifs. Lors de la conception d'une base de données, vous voulez vous assurer que toutes les données d'une table sont liées à elle-même. C'est comme le jeu de cet enfant qui consiste à repérer ce qui est différent. Si vous avez une banane, une fraise, une pêche et un poste de télévision, le poste de télévision appartient probablement ailleurs.
Dans le même ordre d'idées, si vous avez un tableau des vendeurs, toutes les informations qu'il contient doivent concerner spécifiquement ce vendeur. Toute information supplémentaire qui n'est pas propre à ce vendeur peut appartenir à une autre partie de votre base de données.
| SalesID | Premier | Dernier | Adresse | Numéro de téléphone | Bureau | Numéro de bureau |
| 1 | Sam | Elliot | 118 rue principale, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Forgeron | 504 2nd Street, New York, NY | (211) 122-1821 | New York (Est) | (211) 855-4541 |
| 3 | Joe | Paroisse | 428 Aker St, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Bien que cette table puisse avoir l’impression que tout soit lié au vendeur individuel, elle contient en fait une table intégrée dans la table. Notez comment Office et OfficeNumber répètent avec "Austin Downtown". Et si un numéro de téléphone au bureau change? Vous auriez besoin de mettre à jour tout un ensemble de données pour un seul élément d'information, ce qui n'est jamais une bonne chose. Ces champs doivent être déplacés vers leur propre table.
| SalesID | Premier | Dernier | Adresse | Numéro de téléphone | OfficeID |
| 1 | Sam | Elliot | 118 rue principale, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Forgeron | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Paroisse | 428 Aker St, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Bureau | Numéro de bureau |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | New York (Est) | (211) 855-4541 |
Ce type de conception vous permet également d'ajouter des informations supplémentaires à la table Office sans créer de fouillis dans la table des vendeurs. Imaginez tout le travail que vous feriez pour simplement garder trace de l'adresse, de la ville, de l'état et du code postal si toutes ces informations étaient dans le tableau des vendeurs!
Erreur de base de données n ° 3: mettre deux ou plusieurs éléments d'information dans un seul champ
L’intégration des informations de bureau dans la table des vendeurs n’était pas le seul problème de cette base de données. Le champ d'adresse contenait trois informations: l'adresse, la ville et l'état. Chaque champ de la base de données ne doit contenir qu'un seul élément d'information. Lorsque vous avez plusieurs informations dans un même champ, il peut s'avérer plus difficile d'interroger la base de données.
Par exemple, si nous voulions lancer une requête sur tous les vendeurs d’Austin? Nous aurions besoin de chercher dans le champ d'adresse, ce qui est non seulement inefficace, mais peut renvoyer de mauvaises informations. Après tout, que se passe-t-il si quelqu'un vivait dans la rue Austin à Portland, en Oregon?
Voici à quoi devrait ressembler le tableau:
| SalesID | Premier | Dernier | Adresse 1 | Adresse 2 | Ville | Etat | Zip *: français | Téléphone |
| 1 | Sam | Elliot | 118 rue Main | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Forgeron | 504 2nd St | New York | New York | 10022 | 2111221821 | |
| 3 | Joe | Paroisse | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Il y a quelques choses à noter ici.Premièrement, "Address1" et "Address2" sembleraient tomber dans l'erreur de champs répétitifs.
Cependant, dans ce cas, ils font référence à des données distinctes se rapportant directement au vendeur plutôt qu’à un groupe répétitif de données devant figurer dans son propre tableau.
En outre, comme erreur supplémentaire à éviter, notez comment le formatage du numéro de téléphone a été supprimé du tableau. Vous devez éviter de stocker le format des champs dans la mesure du possible. Dans le cas des numéros de téléphone, les personnes écrivent un numéro de plusieurs manières: 215-555-5858 ou (215) 555-5858. Cela rendrait plus difficile la recherche d’un vendeur par son numéro de téléphone ou la recherche d’un vendeur se trouvant dans le même indicatif régional.
Erreur de base de données n ° 4: ne pas utiliser une clé primaire correcte
Dans la plupart des cas, vous souhaiterez utiliser un numéro incrémentant automatiquement ou un autre numéro généré ou alphanumérique pour votre clé primaire. Vous devez éviter d'utiliser des informations réelles pour la clé primaire, même si cela semble donner un bon identifiant.
Par exemple, nous avons chacun notre propre numéro de sécurité sociale. Par conséquent, l’utilisation du numéro de sécurité sociale pour une base de données d’employés peut sembler une bonne idée. Même si cela est rare, même un numéro de sécurité sociale peut changer, et nous ne voulons jamais que notre clé principale change.
Et c’est le problème que pose l’utilisation des informations réelles en tant que valeur clé. Ça peut changer.
Erreur de base de données n ° 5: ne pas utiliser de convention de dénomination
Cela peut ne pas sembler un gros problème lorsque vous commencez à concevoir votre base de données, mais une fois que vous en êtes arrivé à écrire des requêtes sur la base de données pour récupérer des informations, une convention de dénomination vous aidera à mémoriser les noms de champs.
Imaginez à quel point ce processus serait plus difficile si les noms étaient stockés sous les noms FirstName, LastName dans une table et first_name, Last_name dans une autre table.
Les deux conventions de dénomination les plus courantes consistent à mettre la première lettre de chaque mot du champ en majuscule ou à séparer les mots à l'aide d'un trait de soulignement. Vous pouvez également voir des développeurs mettre en majuscule la première lettre de chaque mot sauf le premier: firstName, lastName.
Vous voudrez également décider d'utiliser des noms de table au singulier ou des noms de table à plusieurs. Est-ce une table Order ou une table Orders? Est-ce une table client ou une table clients? Encore une fois, vous ne voulez pas être coincé avec une table Order et une table Customers.
La convention de dénomination que vous choisissez n'est pas aussi importante que le processus consistant à choisir et à respecter une convention de dénomination.
Erreur de base de données n ° 6: indexation incorrecte
L'indexation est l'une des choses les plus difficiles à maîtriser, en particulier pour les débutants en conception de base de données. Toutes les clés primaires et étrangères doivent être indexées. Ce sont ces tableaux de liens, donc sans index, vous constaterez des performances très médiocres pour votre base de données.
Mais ce qui manque trop souvent, ce sont les autres domaines. Ce sont les champs "WHERE". Si vous allez souvent restreindre votre recherche en utilisant un champ dans une clause WHERE, vous voulez penser à mettre un index sur ce champ. Cependant, vous ne voulez pas trop indexer la table, ce qui peut également nuire aux performances.
Comment décider? Cela fait partie de l'art de la conception de bases de données. Il n'y a pas de limite stricte sur le nombre d'index que vous devez mettre sur une table. En premier lieu, vous souhaitez indexer tout champ fréquemment utilisé dans une clause WHERE. En savoir plus sur l'indexation correcte de votre base de données.
