Optimisation de votre SGBDR et de vos requêtes...

[pinocchio]

Envoyé par Barbibulle

Code :

INSERT INTO matable (col, col2) VALUES ('..','...');

ou

Code :

INSERT INTO matable VALUES ('..', '...');

et un

il y'a également le

Code :

1
2
INSERT INTO matable (col, col2) 
SELECT ..,.. FROM monautretable WHERE condition;

ou

Code :

1
2
INSERT INTO matable
SELECT ..,.. FROM monautretable WHERE condition

Le tout étant d'avoir les valeurs en accord avec le type des colonnes matable.

[tung-savate]

Envoyé par SQLpro

Voici :

Code :

Absence de la clause de liste des noms des colonnes => le SGBDR va avoir à faire des requêtes supplémentaires pour aller à la recherche de cas colonnes.

Code :

On passe la liste complete des colonnes, et pour celles non renseignée on spécifie des marquers NULL. Or NULL est par défaut en cas d'absence de spécification de la colonne. Donc, redondance et texte de requête plus long que :

Code :

A +

et dans le cas où tu as une valeur null à insérer au milieu des données, vaux mieux t-il rien entrer ou d'entrer la valeur null ??

Code :

1
2
3
-- cas 1 : laisser à vide
   INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM, CLI_VILLE) 
          VALUES (198, 'M.', 'DUCORNET', 'Archibald',,'LYON')

Code :

1
2
3
-- cas 2 : renseigner la valeur null 
   INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM,CLI_VILLE) 
          VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL,'LYON')

[annedjomo]

Si j'ai bien suivi les explications , c'excellent de faire ceci

Code :

1
2
INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM,CLI_VILLE) 
          VALUES (198, 'M.', 'DUCORNET', 'Archibald', 'LYON')

[dark_vidor]

Envoyé par SQLpro

Voici :

Code :

Absence de la clause de liste des noms des colonnes => le SGBDR va avoir à faire des requêtes supplémentaires pour aller à la recherche de cas colonnes.

Code :

...

Es ce que une requete de ce type :

Code :

INSERT INTO T_CLIENT SET CLI_ID =198, TIT_CODE = 'M.', CLI_NOM = 'DUCORNET', CLI_PRENOM = 'Archibald', CLI_ENSEIGNE = NULL

qui fonctionne parfaitement est pour le serveur une requete qui va prendre plus de ressource ?
Ce type de requete est il lourd à gerer ?

[SQLpro]

C'est requête n'existe pas en SQL. SQL est un langage normatif, dont la syntaxe est basée sur la norme ISO SQL 2, SQL:1999 ou SQL:2003.

En l'occurence cette syntaxe :

Code :

1
2
3
4
5
6
INSERT INTO T_CLIENT 
SET CLI_ID =198, 
    TIT_CODE = 'M.', 
    CLI_NOM = 'DUCORNET', 
    CLI_PRENOM = 'Archibald', 
    CLI_ENSEIGNE = NULL

n'existe nulle part dans la norme. C'est une invention d'un éditeur (MySQL AB) qui en cela rend sciement incompatible les requêtes SQL d'insertion afin de rendre le portage d'un développement fait avec ce SGBDR difficile sans doute pour se protéger.

Ici nous parlons du langage SQL pas de MySQL !

A +

[ced]

Juste une petite question sur cet excellent article
Dans la liste des transformations usuelles, la règle 12 préconise de transformer les "coalesce" en "union", mais la règle 16 transforme les "union" en "jointure" par le biais de la fonction "coalesce".
Ca semble un peu antagoniste, vu de loin ? Dans quel cas "coalesce" pose-t-il un problème de performances ? Quand il est utilisé sur plusieurs champs différents mais dans une même "formule", comme ça semble être le cas de l'exemple 12 ?

Personnellement, j'ai déjà constaté les différences de performances décrites dans la règle 16, et j'évite, autant que possible, l'union pour ces raisons. Mais là, je ne comprends plus bien...

Merci d'avance,

ced

[Monstros Velu]

Envoyé par ced

la règle 12 ... la règle 16

Je me posais la même question

[SQLpro]

Une fonction ne permet pas l'utilisation d'un index.

L'UNION permet de séparer en deux requêtes qui peuvent être "sargeable" (utilsation des index à disposition).

La jointure se base généralement sur clef primaire / clef étrangères qui en principe doivent toutes deux êtres indexées, donc choix pour le moteur SQL de l'index.

Dans la graduation chaque de ces transformation peuvent s'avérer plus performantes. Cela nécessite quand même de mesurer la chose... et dépend du moteur SQL !

A +

[ldiaz]

Salut a tous,
j'ai lu avec attention ces postes...super interessant.
J'ai une question, a un moment vous parlez de ceci:

"Si tu laisse le modèle 1 et que tu as 30 000 personnes dans ta table, cela fait : 68 * 2 octets * 30 000 = 4 Mega Octets dans ta table.

Si tu normalise au maximum, cette même table aura :
6 * 2 octets * 30 000 = 0.36 Mega Octets dans ta table
"
Je comprend le 2 octets et le 30 000 mais j'arrive pas a piger a quoi corrrespond le 68 de la premiere requete et le 6 de la seconde...

Tu peux m'eclairer?
D'avance merci

[djouk]

Bonjour ,
Merci beaucoup rien a dire chapeau pour vous

[StringBuilder]

Envoyé par SQLpro

Voici :

Code :

On passe la liste complete des colonnes, et pour celles non renseignée on spécifie des marquers NULL. Or NULL est par défaut en cas d'absence de spécification de la colonne.
A +

Pour moi, c'est plus grave que ça : si j'ai des DEFAULT sur les colonnes, que je met à NULL, alors les valeurs par défaut ne seront pas utilisées. Même pire, si j'ai des DEFAULT NOT NULL, alors je fais avoir des erreurs... que je n'aurais pas en ne spécifiant pas la colonne !

[CinePhil]

Préfère alors la solution marquée par SQLPro comme excellente qui consiste à ne désigner que les colonnes auxquelles tu passes des valeurs. Les autres colonnes ne figurant pas dans la requête prendront leur valeur par défaut, laquelle peut être NULL si c'est spécifié dans la définition de la table.

[cedrick21]

Bonjour,

très bon sujet, auquel j'aimerai apporté une question.
J'ai une table avec une clé primaire qui est en INT(11)
Je sais d'avance que les valeurs n'excéderons jamais les 10 000 ou 15 000.
Je pourrais donc réduire le tout à un SMALLINT

Mais je me pose la question suivante :
Qu'est-ce qui va faire que ma table sera mieux optimisée comme cela ?
Est-ce que ça sera forcément plus rapide ? si oui pourquoi ?

Ce sont des questions très bêtes, mais j'aime savoir le pourquoi du comment.

Merci d'avance

[CinePhil]

En SMALLINT, ta colonne va occuper deux fois moins d'espace qu'en INT.
L'index sera également moins volumineux je pense.

Pour la table en elle-même, avec les performances atteintes par les ordinateurs aujourd'hui, la différence ne sera pas humainement sensible.

Par contre, si cette table doit être jointe à une autre beaucoup plus grosse (millions de lignes), ça peut devenir sensible.

[fsmrel]

Bonjour,

Envoyé par CinePhil

En SMALLINT, ta colonne va occuper deux fois moins d'espace qu'en INT.
L'index sera également moins volumineux je pense.

L’index est de fait moins volumineux. Par exemple avec DB2 for z/OS, si la table de cedrick21 contient 16 000 lignes, la consommation en kilooctets de l’index sera de l’ordre de 160 dans le cas de SMALLINT et 190 dans le cas de INTEGER, pas de quoi fouetter un chat.

Plus important : l’accès à un enregistrement sur le disque est de l’ordre de 10 millisecondes et cela indépendamment de la puissance du processeur.
Or la taille de la clé joue sur la hauteur de l’arbre représenté par l’index (nombre de niveaux à traverser) et il faut bien plus de temps pour traverser un index de hauteur 5 qu’un index de hauteur 2.

Dans le cas de l’index hébergeant la clé primaire de cedrick21, il n’y a pas de problème, car, si l’attribut constituant la clé primaire est de type INTEGER, la hauteur de l’arbre est égale à 2 pour un nombre de clés (donc de lignes) de l’ordre de 130 000 pour passer à 3 quand le nombre de clés monte à 140 000.
A titre indicatif, si l’attribut constituant la clé primaire est de type SMALLINT, la hauteur de l’arbre est égale à 2 pour un nombre de clés (donc de lignes) de l’ordre de 200 000 pour passer à 3 quand le nombre de clés monte à 210 000.

cedrick21 n'a pas de souci à se faire...

[SQLpro]

Envoyé par StringBuilder

Pour moi, c'est plus grave que ça : si j'ai des DEFAULT sur les colonnes, que je met à NULL, alors les valeurs par défaut ne seront pas utilisées. Même pire, si j'ai des DEFAULT NOT NULL, alors je fais avoir des erreurs... que je n'aurais pas en ne spécifiant pas la colonne !

Vous pouvez aussi spécifier DEFAULT à la place de NULL

A +