Chaque fois que vous, en tant que développeur, vous recevez une tâche basée sur du code existant, vous devez faire face à de nombreux défis. L'un de ces défis - le plus souvent le plus exigeant - consiste à comprendre le modèle de données d'une application.

Vous êtes normalement confronté à des tables, des vues, des colonnes, des valeurs, des procédures stockées, des fonctions, des contraintes et des déclencheurs déroutants qui prennent beaucoup de temps à avoir un sens pour vous. Et, une fois qu'ils le font, vous commencez à remarquer de nombreuses façons d'améliorer et de tirer parti des informations stockées.

Si vous êtes un développeur expérimenté, il y a de fortes chances que vous remarquiez également des choses qui auraient pu être mieux faites au début, c'est-à-dire des défauts de conception.

Dans cet article, vous découvrirez certaines des mauvaises pratiques courantes de conception de bases de données, pourquoi elles sont mauvaises et comment vous pouvez les éviter.

Mauvaise pratique n ° 1: ignorer la finalité des données

Les données sont stockées pour être consommées plus tard, et le but est toujours de les stocker et de les récupérer de la manière la plus efficace. Pour y parvenir, le concepteur de la base de données doit savoir à l'avance ce que les données vont représenter, comment vont-elles être acquises et à quel rythme, quel sera son volume opérationnel (c'est-à-dire quelle quantité de données est attendue), et enfin , comment il va être utilisé.

Par exemple, un système d'information industriel où les données sont collectées manuellement tous les jours n'aura pas le même modèle de données qu'un système industriel où les informations sont générées en temps réel. Pourquoi? Parce qu'il est très différent de gérer quelques centaines ou milliers d'enregistrements par mois par rapport à gérer des millions d'entre eux dans la même période. Des considérations spéciales doivent être prises par les concepteurs afin de maintenir l'efficacité et la convivialité de la base de données, si les volumes de données doivent être importants.

Mais, bien sûr, le volume de données n'est pas le seul aspect à prendre en compte, car le but des données affecte également le niveau de normalisation, la structure des données, la taille de l'enregistrement et la mise en œuvre générale de l'ensemble du système.

Par conséquent, la connaissance approfondie de l'objectif du système de données que vous allez créer conduit à des considérations dans le choix du moteur de base de données, des entités à concevoir, de la taille et du format d'enregistrement et des politiques de gestion du moteur de base de données.

Ignorer ces objectifs mènera à des conceptions qui présentent des défauts dans leurs bases, bien que structurellement et mathématiquement correctes.

Mauvaise pratique n ° 2: mauvaise normalisation

La conception d'une base de données n'est pas une tâche déterministe; deux concepteurs de bases de données peuvent suivre toutes les règles et principes de normalisation pour un problème donné et, dans la plupart des cas, ils génèrent des présentations de données différentes. Ceci est inhérent à la nature créative du génie logiciel. Cependant, il existe certaines techniques d'analyse qui ont du sens dans chaque cas, et les suivre est le meilleur moyen d'accéder à une base de données qui fonctionne au mieux.

Malgré cela, nous sommes souvent confrontés à des bases de données qui ont été conçues à la volée sans suivre les règles les plus élémentaires de normalisation. Nous devons être clairs à ce sujet: chaque base de données doit, au moins, être normalisée à la troisième forme normale, car c'est la mise en page qui représentera le mieux vos entités et dont les performances seront le mieux équilibrées entre l'interrogation et l'insertion-mise à jour-suppression d'enregistrements .

Si vous tombez sur des tables qui ne sont pas conformes 3NF , 2NF, voire 1NF, envisagent de reconcevoir ces tableaux. L'effort que vous investissez pour ce faire sera payant à très court terme.

w2 taux horaire vs calculateur de salaire

Mauvaise pratique n ° 3: Redondance

Très lié au point précédent, car l'un des objectifs de normalisation est de le réduire, la redondance est une autre mauvaise pratique qui apparaît assez souvent.

Les champs et les tables redondants sont un cauchemar pour les développeurs, car ils nécessitent une logique métier pour maintenir à jour de nombreuses versions des mêmes informations. C'est une surcharge qui peut être évitée si les règles de normalisation sont suivies à fond. Si la redondance peut parfois sembler nécessaire, elle ne doit être utilisée que dans des cas très spécifiques et être clairement documentée afin d'être prise en compte dans les développements futurs.

Les effets négatifs typiques de la redondance sont une augmentation inutile de la taille de la base de données, des données sujettes à des incohérences et une diminution de l'efficacité de la base de données, mais - plus important encore - cela peut entraîner une corruption des données.

Mauvaise pratique n ° 4: mauvaise intégrité référentielle (contraintes)

L'intégrité référentielle est l'un des outils les plus précieux fournis par les moteurs de base de données pour maintenir la qualité des données à son meilleur. Si aucune contrainte ou très peu de contraintes sont implémentées dès la conception, l'intégrité des données devra reposer entièrement sur la logique métier, ce qui la rend vulnérable aux erreurs humaines.

Mauvaise pratique n ° 5: ne pas tirer parti des fonctionnalités du moteur DB

Lorsque vous utilisez un moteur de base de données (DBE), vous disposez d'un logiciel puissant pour vos tâches de traitement des données qui simplifiera le développement logiciel et garantira que les informations sont toujours correctes, sûres et utilisables. Un DBE fournit des services tels que:

• Vues qui fournissent un moyen rapide et efficace d'examiner vos données, en les dé-normalisant généralement à des fins de requête sans perdre l'exactitude des données.
• Index qui aident à accélérer les requêtes sur les tables.
• Fonctions d'agrégation qui aident à analyser les informations sans programmation.
• Transactions ou blocs de phrases modifiant les données qui sont tous exécutés et validés ou annulés (annulés) si quelque chose d'inattendu se produit, maintenant ainsi les informations dans un état perpétuellement correct.
• Verrous qui gardent les données en sécurité et correctes pendant l'exécution des transactions.
• Procédures stockées qui fournissent des fonctionnalités de programmation pour permettre des tâches de gestion de données complexes.
• Fonctions qui permettent des calculs sophistiqués et des transformations de données.
• Contraintes qui aident à garantir l'exactitude des données et à éviter les erreurs.
• Déclencheurs qui aident à automatiser les actions lorsque des événements se produisent sur les données.
• Optimiseur de commande (planificateur d'exécution) qui fonctionne sous le capot, garantissant que chaque phrase est exécutée au mieux et gardant les plans d'exécution pour les occasions futures. C'est l'une des meilleures raisons d'utiliser des vues, des procédures stockées et des fonctions, car leurs plans d'exécution sont conservés en permanence dans le DBE.

Ne pas connaître ou ignorer ces capacités amènera le développement sur une voie extrêmement incertaine et sûrement vers des bogues et des problèmes futurs.

Mauvaise pratique n ° 6: Clés primaires composites

C'est en quelque sorte un point controversé, car de nombreux concepteurs de bases de données parlent aujourd'hui d'utiliser un champ généré automatiquement par ID entier comme clé primaire au lieu d'un champ composite défini par la combinaison de deux champs ou plus. Ceci est actuellement défini comme la «meilleure pratique» et, personnellement, j'ai tendance à être d'accord avec elle.

Cependant, il ne s'agit que d'une convention et, bien sûr, les DBE permettent la définition de primaire composite clés, que de nombreux concepteurs pensent inévitables. Par conséquent, comme pour la redondance, les clés primaires composites sont une décision de conception.

Attention, cependant, si votre table avec une clé primaire composite doit avoir des millions de lignes, l'index contrôlant la clé composite peut croître jusqu'à un point où les performances de l'opération CRUD sont très dégradées. Dans ce cas, il est préférable d'utiliser une simple clé primaire d'ID entier dont l'index sera suffisamment compact et établira les contraintes DBE nécessaires pour maintenir l'unicité.

Mauvaise pratique n ° 7: mauvaise indexation

Parfois, vous aurez une table que vous devrez interroger par plusieurs colonnes. Au fur et à mesure que la table grandit, vous remarquerez que les SELECT sur ces colonnes ralentissent. Si la table est assez grande, vous penserez, logiquement, à créer un index sur chaque colonne que vous utilisez pour accéder à cette table uniquement pour constater presque immédiatement que les performances des SELECT s'améliorent mais que les INSERTs, UPDATE et DELETEs chutent. Ceci, bien sûr, est dû au fait que les index doivent être synchronisés avec la table, ce qui signifie une surcharge massive pour le DBE. Il s'agit d'un cas typique de surindexation que vous pouvez résoudre de plusieurs manières; Par exemple, avoir un seul index sur toutes les colonnes différentes de la clé primaire que vous utilisez pour interroger la table, ordonner ces colonnes de la plus utilisée à la moins peut offrir de meilleures performances dans toutes les opérations CRUD qu'un index par colonne.

D'un autre côté, avoir une table sans index sur les colonnes qui sont utilisées pour l'interroger entraînera, comme nous le savons tous, une mauvaise performance sur les SELECT.

En outre, l'efficacité de l'index dépend parfois du type de colonne; les index sur les colonnes INT présentent les meilleures performances possibles, mais les index sur VARCHAR, DATE ou DECIMAL (si cela a du sens) ne sont pas aussi efficaces. Cette considération peut même conduire à une refonte des tables auxquelles il faut accéder avec la meilleure efficacité possible.

Par conséquent, l'indexation est toujours une décision délicate, car trop d'indexation peut être aussi mauvaise que trop peu et parce que le type de données des colonnes à indexer a une grande influence sur le résultat final.

Mauvaise pratique n ° 8: mauvaises conventions de dénomination

C'est quelque chose avec lequel les programmeurs ont toujours du mal à faire face à une base de données existante: comprendre quelles informations y sont stockées par les noms des tables et des colonnes car, souvent, il n'y a pas d'autre moyen.

société britannique de services bancaires et financiers

Le nom de la table doit décrire l'entité qu'elle contient et chaque nom de colonne doit décrire quel élément d'information il représente. C'est facile, mais cela commence à être compliqué lorsque les tables doivent être liées les unes aux autres. Les noms commencent à devenir désordonnés et, pire, s'il existe des conventions de dénomination confuses avec des normes illogiques (comme, par exemple, «le nom de la colonne doit contenir 8 caractères ou moins»). La conséquence finale est que la base de données devient illisible.

Par conséquent, un convention de dénomination est toujours nécessaire si la base de données est censée durer et évoluer avec l'application qu'elle prend en charge, et voici quelques conseils pour en établir une succincte, simple et lisible:

• Aucune limitation sur la taille des noms de table ou de colonne. Il vaut mieux avoir un nom descriptif qu'un acronyme dont personne ne se souvient ou ne comprend.
• Les noms égaux ont la même signification. Évitez d'avoir des champs qui ont le même nom mais avec des types ou des significations différents; ce sera déroutant tôt ou tard.
• Sauf si nécessaire, ne soyez pas redondant. Par exemple, dans le tableau «Item», il n'est pas nécessaire d'avoir des colonnes comme «ItemName», «PriceOfItem» ou des noms similaires; «Nom» et «Prix» suffisent.
• Méfiez-vous des mots réservés DBE. Si une colonne doit s'appeler «Index», qui est un mot réservé SQL, essayez d'en utiliser une autre comme «IndexNumber».
• Si vous vous en tenez à la règle de la clé primaire simple (un seul entier généré automatiquement), nommez-le «Id» dans chaque table.
• Si vous vous joignez à une autre table, définissez la clé étrangère nécessaire sous la forme d'un entier, nommé «Id» suivi du nom de la table jointe (par exemple, IdItem).
• Si vous nommez des contraintes, utilisez un préfixe décrivant la contrainte (par exemple, «PK» ou «FK»), suivi du nom de la ou des tables concernées. Bien entendu, l'utilisation de traits de soulignement («_») avec parcimonie permet de rendre les choses plus lisibles.
• Pour nommer les index, utilisez le préfixe «IDX» suivi du nom de la table et de la ou des colonnes de l'index. Utilisez également «UNIQUE» comme préfixe ou suffixe si l'index est unique, et des traits de soulignement si nécessaire.

Il existe de nombreuses directives de dénomination de bases de données sur Internet qui éclaireront davantage cet aspect très important de la conception de bases de données, mais avec ces règles de base, vous pouvez au moins accéder à une base de données lisible. Ce qui est important ici, ce n'est pas la taille ou la complexité de vos directives de dénomination, mais votre cohérence à les suivre!

Quelques remarques finales

La conception de bases de données est une combinaison de connaissances et d'expérience; l'industrie du logiciel a beaucoup évolué depuis ses débuts. Heureusement, il y a suffisamment de connaissances disponibles pour aider concepteurs de bases de données obtenir les meilleurs résultats.

Il existe une bonne conception de base de données des lignes directrices partout sur Internet ainsi que mauvaises pratiques et choses à éviter dans la conception de bases de données. Faites votre choix et respectez-le.

Et, n'oubliez pas, ce n'est que par l'expérimentation, les erreurs et les succès que vous apprenez, alors allez-y et commencez maintenant.