Concevoir une base de données n'est pas une tâche facile. Même les experts font parfois des erreurs. Connaître la théorie des bases de données et s'armer de bonnes intentions ne suffit pas ; les entreprises doivent s'assurer que le concepteur de base de données ne tombe pas dans l'un des pièges classiques. Voici les dix erreurs les plus communes :

Erreur n°1: Mal planifier le projet
Selon Deb Woods, vice président en charge de la gestion des produits chez Ingres, la première erreur consiste à ne pas planifier le projet correctement. On peut éviter de nombreux désagréments en portant une attention particulière à la conception de la base de données et à la façon dont elle va être utilisée dès le départ. De nombreux éléments méritent attention : choisir la base de données, déterminer comment elle interagit avec l'application, ou déterminer les critères de sécurité ainsi que les besoins en matière de sauvegarde et de restauration.

Erreur n°2: Mal choisir la base de données
Toutes les bases de données ne se valent pas. Celle que vous avez sélectionnée fait-elle tout ce que vous voulez ? Fonctionne-t-elle avec les bons outils ? La plupart des fournisseurs proposent maintenant une démonstration de validation de concept, pour permettre aux entreprises de s'assurer que la base de données choisie couvre bien tous les besoins.

Erreur n°3: Mal choisir le matériel
Certaines bases de données fonctionnent parfaitement sur des plates-formes matérielles standard. Mais d'autres nécessitent un équipement spécialisé pour donner le meilleur d'elles-mêmes. Regardez la façon dont Oracle s'est associé à HP ou Sun pour proposer des appliances spécialisées dans le transactionnel (OLTP) ou dans les entrepôts de données, ou encore la récente annonce d'IBM au sujet de DB2 PureScale. Ce dernier n'est pas formellement packagé sous la forme d'une appliance, mais ne tourne que sur la gamme Power Servers d'IBM.

Erreur n°4: Ne pas documenter les développements correctement
L'absence de documentation correcte est une faiblesse qui touche toutes les formes de programmation - pas seulement la conception de base de données. Les développements se trouvent très souvent ralentis lorsque les programmeurs se voient obligés de reprendre du code mal documenté écrit par leurs prédécesseurs. Ne pas documenter les modifications de manière suffisamment régulière et précise va forcément se solder par un problème, à un moment ou à un autre.

Erreur n°5: Utiliser des raccourcis de langages propriétaires
Il peut être très tentant d'utiliser des raccourcis dans un langage propriétaire, au lieu d'utiliser du code SQL standard. Il faut pourtant éviter de le faire. Les programmeurs vont peut-être gagner 10 ou 15 minutes lors de l'étape de développement, mais le jeu n'en vaut pas la chandelle si l'on considère les coûts de licence et de développement que la société va devoir payer à long terme. C'est la raison pour laquelle Deb Woods d'Ingres conseille de se cantonner à la version standard de SQL, y compris avec des systèmes propriétaires tels que ceux d'Oracle, de Sybase ou d'IBM.

Erreur n°6: Ne pas savoir gérer le changement
C'est un fait, les applications évoluent. Et parfois, les bases de données aussi, dans leur sillon. Les changements doivent être effectués avec précautions. Des modifications mineures dans la structure de tables peuvent, fort vicieusement, ralentir à l'extrême une fonction auparavant très rapide. De plus, bien souvent, lorsque les entreprises modifient les applications et les propriétés des bases de données, elles jettent les règles métier par-dessus bord par la même occasion.

« J'ai récemment été témoin d'un exemple où le système semblait bogué. Mais en fait, ce qui s'était vraiment passé, c'est que les responsables métier l'avaient configuré sans respecter l'une des conditions initiales définies d'un commun accord; cela a affecté l'un des paramètres clé de l'architecture de la base de données, et le système a commencé à renvoyer des résultats imprévisibles » , explique David Cartwright, responsable réseaux, télécoms et hébergement networks chez la compagnie financière CPA Global, et également développeur de bases de données.

Erreur n°7: Normaliser les structures de données à l'extrême
La conception classique de bases de données, telle que promue par le pionnier des bases de données relationnelles Ted Codd, préconise que les bases de données soient aussi normalisées que possible - c'est-à-dire que la structure de la base de données convient à des requêtes généralistes et est exempte d'anomalies lors de l'insertion de données, de mises à jours et d'effacements. Cartwright souligne que dans la pratique, c'est bien trop rigoureux pour un usage courant: les administrateurs de bases de données qui tiennent à normaliser à l'extrême les structures de données et à éliminer entièrement la duplication de données sont certains de tuer les performances de toute base de données, à l'exception des plus simplistes.

Erreur n°8: Considérer que toutes les bases de données se valent
Toutes les bases de données suivent de nombreux principes communs, sont basées sur le même type de structure sous-jacente et sont exploitées au travers de requêtes SQL, cependant il est important de réaliser qu'elles ne sont pas identiques pour autant - ce qui ne signifie pas que certaines sont meilleures que d'autres. Les administrateurs de bases de données qui comprennent les faiblesses et atouts de systèmes de gestion de bases de données comprennent que ce qui est optimal, par exemple, dans Oracle 11g, ne sera peut être pas aussi efficace dans SQL Server de Microsoft.

Erreur n°9: Faire des économies de personnel
Toute entreprise qui envisage avec sérieux un projet de déploiement de base de données doit se préparer à dépenser de l'argent pour s'assurer les services de personnes bien qualifiées pour la concevoir et la gérer, selon David Cartwright. « Vous pensez peut-être qu'un administrateur de bases de données et un architecte qualifié coûtent cher. Mais cela ne revient pas aussi cher que de choisir des personnes à moitié qualifiées, puis de se retrouver avec une base de donnée qui pédale dans la semoule dès qu'on lui applique un peu de charge", explique-t-il.

Erreur n°10: Laisser les gens travailler de manière isolée
Pour Deb Woods d'Ingres, il est tout aussi important que toutes les personnes de l'entreprise impliquées dans le projet travaillent ensemble. L'approche du travail ne peut plus être compartimentée. Toutes les entités de l'entreprise doivent communiquer et coopérer. « Pour l'entreprise, la façon de procéder la plus rentable est lorsque toutes les personnes impliquées - c'est à dire les CIO, administrateurs de bases de données, développeurs et responsables système - travaillent ensemble," conclut Deb Woods.