Archives pour la catégorie tuning

[SGBD] [Optimisation] Pourquoi l’écriture de fonctions encapsulées est à bannir en SQL ?

Je voudrais revenir sur un article de Rudi éclairant pour moi :

http://rudi.developpez.com/sqlserver/tutoriel/optimisation/

Dans cet article, il écrit « Une erreur commune, qui peut affecter fortement les performances, est d’écrire du code SQL avec la même approche intellectuelle que pour l’écriture de code procédural. »
Lire la suite

A quel moment doit avoir lieu l’optimisation d’une base ?

L’ importance de la normalisation de la base est essentiel. Le modèle relationnelle a fait passer le gros du travail de la partie développement à la partie conception.
L’ Architecte de la base, premier intervenant du projet, qui utilise POWER AMC ou Toad Data Modeler doit respecter absolument la 3 ème forme normale dans la définition de son modèle. On ne peut pas faire l’ économie d’un modéle relationnel dans la conception d’ une application.

Le deuxième pôle de l’ optimisation est le soin apporté à l’ écriture du SQL. Privilégié le plus possible l’ écriture de SQL à l’ écriture de Transact SQL. L’ utilisation de SQL permet l’ indexation et des performances supérieurs. Par exemple, la semaine dernière, mon patron me signale une application dont les temps de réponses dépassés 30 secondes. Fier de mes connaissances, je propose d’ optimiser la requête par une indexation adéquate. Je passe 3H00 sur la requête pour finalement découvrir que les 30 secondes sont perdus par l’ utilisation en cascade de fonctions. Évidemment, en tant que développeur, on doit répondre à des besoins fonctionnelles et l’encapsulation en fonction répond bien à nos besoins mais en production, avec 100000 lignes dans une table, on perd un temps précieux à l’ exécution.

Le troisième pôle de l’ optimisation est l’ indexation. Sur des tables de plus de 1000 lignes, il devient important d’ indexer. Un produit comme POWER AMC vous facilite le travail puisqu’ il génére la majorité des index à la conception pour des tables bien normalisé.

On découvre donc bien que l’ essentiel de l’ optimisation d’ une base de données ne se passe pas donc pas en production, par le DBA, mais lors de la fabrication, par le développeur et l’architecte de la base.

Ne simplifions pas trop, les développeurs règlent généralement très bien les problèmes apparents et les problèmes de performances apparaissent souvent très tard dans le cycle de vie et entraîne des interventions des DBA. Néanmoins, la montée en charge future d’ une application peut être prévu très tôt par le respect de normes.

Dénormaliser une base de données.

Pour optimiser une requete, la premiere des choses à faire, si la ou les tables comptent plusieurs miliers d’enregistrement avec des valeurs trés différentes, est de placer des index, de faire tourner et de supprimer les index non utilisés. Si vous avez exploré toute les possibilités des index, et que votre requete est toujours trop lente, la solution est la denormalisation. La dénormalisation doit être utilisée sans complexe dans les bases en lecture seule, sans mise à jour. Dans les bases transactionnelles, il est nécessaire de mettre en place des triggers pour assurer la cohérence de la base.

Imaginez deux tables en 3 eme forme normale.
element(idelement,nomelement)
structure(id, nom, idelement )
la dénormalisation consiste à garder element à l’identique et modifier structure de la façon suivante (2 eme forme normale):
structure(id,nom,idelement,nomelement)
ainsi la requete associant element et structure est instantannée…
SELECT id,nom,nomelement from structure.

bon developpement

pour aller plus loin, un debat : http://www.developpez.net/forums/showthread.php?t=6231