Chaque fois qu'en tant que développeur on vous attribue 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 généralement 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 l'ont, 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é, vous remarquerez probablement aussi des choses qui auraient pu être améliorées au début, à savoir 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 l'objectif des données

Les données sont stockées pour être consommées plus tard et l'objectif 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 elles seront acquises et à quelle vitesse, quel sera son volume opérationnel (c'est-à-dire quelle quantité de données est attendue), et enfin comment elles seront 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. Parce que? Parce qu'il est très différent de traiter des centaines ou des milliers d'enregistrements par mois par rapport à gérer des millions d'entre eux dans la même période. Les concepteurs doivent prendre des considérations spéciales pour maintenir l'efficacité et la facilité d'utilisation 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 à considérer 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, une compréhension approfondie de l'objectif du système de données que vous allez créer conduit à des considérations sur le choix du moteur de base de données, les entités à concevoir, la taille et le format de l'enregistrement et les politiques de gestion du moteur de base de données.

Ignorer ces objectifs mènera à des conceptions défectueuses dans leurs aspects fondamentaux, même si elles sont 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, généreront 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 instance et les suivre est le meilleur moyen d'accéder à une base de données qui fonctionne au mieux.

c et c++

Malgré cela, nous sommes souvent confrontés à des bases de données conçues à la volée, sans suivre les règles les plus élémentaires de normalisation. Il faut être clair: chaque base de données doit au moins être normalisée à la troisième forme normale puisque c'est la conception qui représentera le mieux ses entités et dont les performances seront mieux équilibrées entre les requêtes et les enregistrements d'insertion-mise à jour-suppression.

Si vous rencontrez des tables qui ne correspondent pas 3NF , 2NF, voire 1NF, envisagent de reconcevoir ces tableaux. L'effort que vous y consacrez sera rentable en très peu de temps.

Mauvaise pratique n ° 3: Redondance

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

créez votre propre langage de programmation

Les champs et les tables redondants sont un cauchemar pour les développeurs car ils nécessitent une logique métier pour maintenir une grande partie des mêmes informations à jour. C'est une surcharge qui peut être évitée si les règles de normalisation sont suivies à la lettre. Bien que la redondance puisse parfois sembler nécessaire, elle ne doit être utilisée que dans des cas très spécifiques et doit être clairement documentée afin qu'elle puisse ê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, les données sont sujettes à des incohérences et une diminution de l'efficacité de la base de données mais - surtout - 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 restriction ou très peu de restrictions ne sont mises en œuvre dès la conception, l'intégrité des données devra dépendre entièrement de la logique métier, ce qui les rend vulnérables aux erreurs humaines.

Mauvaise pratique n ° 5: ne pas tirer parti des fonctionnalités du moteur de base de données

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

• Vues qui fournissent un moyen rapide et efficace d'afficher vos données, généralement désynchronisées à des fins de référence sans perdre l'exactitude des données.

• Index qui aident à accélérer les requêtes de table.

• Ajout de fonctions qui aident à analyser les informations sans programmation.

• Des transactions ou des blocs de phrases qui modifient les données qui sont exécutées et qui sont validées ou annulées (restauration) si quelque chose d'inattendu se produit, maintenant ainsi les informations dans un état correct en permanence.

• Des verrous qui assurent la sécurité et l'exactitude des données pendant l'exécution des transactions.

• Procédures stockées qui fournissent des capacités de planification pour permettre des tâches de gestion de données complexes.

• Fonctions qui permettent des calculs sophistiqués et des transformations de données.

• Restrictions 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 dans les données.

• Commande d'optimisation (planificateur d'exécution) qui s'exécute 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 puisque leurs plans d'exécution sont maintenus en permanence dans le moteur de base de données.

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

Mauvaise pratique n ° 6: clés primaires composites

C'est un point de discorde car de nombreux concepteurs de bases de données parlent aujourd'hui d'utiliser un champ généré automatiquement comme ID primaire comme clé primaire au lieu d'un composé défini en combinant deux champs ou plus. Ceci est actuellement défini comme «meilleure pratique» et j'ai personnellement tendance à être d'accord avec lui.

meilleurs cours de c++

Cependant, ce n'est qu'une convention et bien sûr le moteur de base de données permet la définition de clés primaires composées , ce que de nombreux designers pensent inévitable. Par conséquent, comme pour la redondance, les clés primaires composites sont une décision de conception.

Cependant, gardez à l'esprit que si vous vous attendez à ce que votre table avec une clé primaire composite contienne des millions de lignes, l'index qui contrôle la clé composite peut atteindre un point où les performances de l'opération CRUEL il est très dégradé. Dans ce cas, il est préférable d'utiliser une clé primaire ID simple qui a un index suffisamment compact et définit les contraintes du moteur de base de données nécessaires pour maintenir l'unicité.

Mauvaise pratique n ° 7: mauvaise indexation

Parfois, vous aurez une table que vous devrez interroger pour de nombreuses colonnes. Au fur et à mesure que la table grandit, vous remarquerez que les SELECT dans 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 mais vous remarquerez presque immédiatement que les performances de SELECT s'améliorent, mais INSERT, UPDATE et DELETE tombent. Cela est bien sûr dû au fait que les index doivent être synchronisés avec la table, ce qui signifie une surcharge considérable pour le moteur de base de données. Il s'agit d'un cas typique d'indexation excessive que vous pouvez résoudre de plusieurs manières; Par exemple, avoir un seul index sur toutes les colonnes autres que la clé primaire que vous utilisez pour interroger la table, trier ces colonnes de la plus utilisée à la moins peut offrir de meilleures performances dans toutes les opérations de CRUEL d'un index par colonne.

D'autre part, avoir une table sans index sur les colonnes utilisées pour l'interroger entraînera, comme nous le savons tous, de mauvaises performances sur les SELECT.

De plus, l'efficacité de l'index dépend parfois du type de colonne; Les index sur les colonnes INT affichent 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 tableaux auxquels 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 nomenclature

C'est quelque chose avec lequel les programmeurs ont toujours du mal lorsqu'ils sont confrontés à une base de données existante: comprendre quelles informations y sont stockées par nom de table et de colonne car il n'y a souvent pas d'autre moyen.

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 à devenir délicat lorsque les tables doivent être liées les unes aux autres. Les noms commencent à devenir désordonnés, et pire, s'il y a des conventions de dénomination déroutantes avec des règles illogiques (telles que «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 il 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 directives pour établir une version concise, simple et lisible:

• Aucune limitation sur la taille du nom de la table ou de la colonne. Il vaut mieux avoir un nom descriptif qu'un acronyme dont personne ne se souvient ou ne comprend.

• Les noms identiques 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 'Article', il n'est pas nécessaire d'avoir des colonnes comme 'Nom de l'article', 'Prix de l'article' ou des noms similaires; 'Nom' et 'Prix' suffisent.

• Soyez prudent avec les mots réservés au moteur de base de données. Si une colonne doit être nommée «Index», qui est un mot réservé SQL, essayez d'en utiliser un autre tel que «IndexNumber».

• Si vous vous en tenez à la règle de clé primaire simple (entier unique généré automatiquement), nommez-la «Id» dans chaque table.

• Si vous joignez une autre table, définissez la clé étrangère requise comme un entier, nommé «Id» suivi du nom de la table jointe (par exemple, IdItem).

• Si des contraintes sont nommées, 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 souligné si nécessaire.

Il existe de nombreuses directives de dénomination des 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 étapes de base, vous pouvez au moins accéder à une base de données lisible. L'important ici n'est pas la taille ou la complexité des directives de dénomination, mais leur cohérence dans leur respect!

Quelques observations finales

La conception de la base de données est une combinaison de connaissances et d'expérience; L'industrie du logiciel a beaucoup évolué depuis sa création. Heureusement, il y a suffisamment de connaissances disponibles pour aider aux concepteurs de bases de données pour obtenir les meilleurs résultats.

c-corp ou s-corp

Il y a du bon des lignes directrices dans la conception de bases de données sur Internet, ainsi que mauvaises habitudes Oui choses à éviter dans la conception de la base de données. Choisissez et collez.

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.