salut tout le monde!
je fais une petite appli basée sur une BD (sous Postgresql) et j'essaie d'optimiser mes requêtes. J'aimerais votre avis sur mes options d'optimisations :
- une requête imbriquée, c mieux qu'une jointure (c explain qui me le dit, donc j'espère qu'il a raison   )
- en insert, je désactive l'autocommit
- je mets des char plutôt que des varchar qd je peux
 
j'ai bon?    
 
merci pour vos réponses!

Pour le 2, oui, car si tu as plusieurs insert à la suite dans un traitement, il est important de pouvoir annuler TOUT le traitement.
 
Pour le 3, oui aussi.
 
Pour le 1, pas assez connaisseur en optim pour te répondre, mais j'aurais tendance à préférer une jointure à une requête imbriquée

merci pour tes réponses!    
en fait, c surtt le premier point qui me fait douter!
alors............. up  

Salut bon je suis en 1ère année de DUT Info
 
Et à mon avis il vaut mieux préférer une requete imbriqué qu'une jointure. C'est mon prof qui me l'a dit ....
 
 
Par contre pourquoi mettre des char et pas varchar ?? Moi je croyais que c'était mieux varchar du fait que en fait ça prend monis de place donc ça va plus vite non ?
 
@++

ben nan! varchar n'a pas de taille définie, donc si tu fais des comparaisons de varchar (genre where texte='machin', c plus lent que si tu as une longueur de chaine fixe (et donc un char).

Ah ok merci pour l'explication.

Sinon, pour l'optimisation en temps, tu peux chronométrer tes requêtes sur un certain nombre d'essais. Ainsi, tu verras toi-même ce qui est le plus rapide (qui n'est pas toujours ce qu'on croit!!!)

certes, certes, mais j'ai trouvé mieux!
la fonction explain de postgres est mon amie!!  

Je ne connais pas PosteGRE, mais je connais assez bien Oracle et SQL Server.
 
Pour ces deux denriers :
- Requêtes imbriquées : Beaucoup plus lent que des jointures dans la plupart des cas. Celà dépends surtout des index crées et si les clés étrangères sont correctement indiquées. Mais dans l'absolu, une requête imbriquée peut être plus de deux fois plus lente qu'une jointure (en effet, si tu fait la jointure correctement, sur des tables avec une clé étrangère, le requête ne porte pas sur les données, mais sur l'index, ce qui équivaut à faire une unique requête sur une seule table - l'index se comportant comme une table en fait) La requête imbriquée quant à elle nécessite une première requête, le tri des résultats, puis une seconde requête en se basant sur les résultats précédents. Donc sur une base correctement configurée, c'est beaucoup plus lent. Ceci dit, je ne connais pas les limitations de PosteGRE.
 
- Varchar et Char. A nouveau, dans une base Oracle ou SQL Server, au niveau logique, oui, le varchar est non contraint, mais dans l'absolu, les données sont stockées avec des vides pour combler la place (un varchar(32) prends 32 caractères de longs, ce qui fait que les traîtements sont aussi rapides. Sous Oracle et SQL Server, varchar (varchar2 pour Oracle) sont d'ailleurs préconisés.
 
- Pour ce qui est de l'auto-commit, l'optimiseur a raison. Ceci dit, sur un bon SGBD, même avec l'auto-commit activé, les différences de perfs sont minimes. En effet, tout étant journalisé, le serveur ne flush pas la base tant qu'un autre requête ne se sert pas des nouvelles données, donc les perfs restent identiques par rapport à un auto-commit off (ça c'est la théorie) L'avantage de l'auto-commit, c'est quand même qu'en cas de crash, tu ne perds aucune donnée. Sans l'auto-commit, tu perds tout. Il vaut donc mieu analyser ça au niveau des besoins de cohérence de la base plutôt qu'en terme de perfs (y'a un moment où il faut privilégier la stabilité par rapport aux perfs)
 
Le mieu serait quand même qu'une personne qui connaisse bien PosteGRE voient si les points que j'ai énoncé sont plus ou moins vrais avec PosteGRE. En effet, je le redis, d'ue SGDB à l'autre, ça peut changer du tout au tout.

merci pour ta réponse très détaillée!
je connais plutôt bien postgres et il me semble que tu as raison au moins pour le coup des requêtes imbriquées : c plus rapide si la requête porte sur des champs qui ne sont pas des clés primaires ou étrangères, mais c plus lent ds le cas contraire.
Pour les varchar ou char, sous postgres, c un peu différent je crois : le char(n) est de longueur fixe et complété avec des blancs, le varchar est de longueur fixe mais non complété. Le pire est qd même le format "text" de longueur variable.
 
encore une fois, merci pour les réponses !!!

En effet, le type "text", sur tout les SGBD ne doit jamais être utilisé pour des filtres, a moins d'utiliser un moteur de recherche sur texte intrégral (avec un dictionnaire)
En effet, le format "text" n'est ni plus ni moins qu'un blob utilisant un jeu de caractère au lieu d'être des données binaires brutes.
Donc dans la table, il est stocké en tant qu'un simple pointeur, et la valeur est stockée "à part" dans une zone du tablesace réservée aux données de type blob. Une recherche là-dessus est donc extrêment lente.
 
Pour ce qui est des varchar, en fait, après vérification :
Sous Oracle :
- varchar(x) => Comme un char(x) classique (la chaîne est complété par des blanc)
- varchar2(x) => Comme un varchar(x) au niveau physique (donc pas plus lent) mais les espaces sont supprimés lors des requêtes (l'espace logique du champ correspond à la taille de la donnée qu'il contient)
 
Sous SQL Server, les types varchar(x) et nvarchar(x) se comportent exactement la même chose que le varchar2(x), sauf que le nvarchat est encodé sur 16 bits et non 7 (pour stocker des textes avec un charset étendu, pour le japonnais par exemple) C'est le type recommandé.
 
Voilà
 
PosteGRE étant un peu plus archaïque au niveau de la gestion des chaînes, c'est possible en effet qu'il stocke les varchar(x) sur une longueur variable. Je trouve cependant cela assez bizarre (niveau performance c'est tellement catastrophique que ça ne devrait même pas exister... mais il est vrai que certains "vieux" SGBD utilisent cette technique)

nanan, postgres stock pas les varchar sur des taille variables!
si tu lui dit varchar(16), il réserve un taille de 16, mais si la valeur à moins de 16, il ne remplit pas le reste par des blancs, c tout,. Il me semble que ça se raproche du varchar2 d'oracle
 
PS: mais heu, il est pas archaique postgres, il marche très bien!!

Il est quand même pasé sur Ingre (d'où le "GRE" à la fin), qui est un des tout premiers SGBD.
Sa structure est archaïque de ce fait, car s'il a évolué, il n'en reste pas moins architecturé autour d'un des tous premiers noyaux de base de données.