IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage SQL Discussion :

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


Sujet :

Langage SQL

  1. #21
    Membre éprouvé Avatar de pinocchio
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2002
    Messages
    795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Service public

    Informations forums :
    Inscription : Novembre 2002
    Messages : 795
    Points : 960
    Points
    960
    Par défaut
    Citation Envoyé par Barbibulle
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO matable (col, col2) VALUES ('..','...');
    ou
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO matable VALUES ('..', '...');
    et un
    il y'a également le
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO matable (col, col2) 
    select ..,.. from monautretable where condition;
    ou
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    La SNCF est mon ami
    blog PARIS-GRANVILLE
    Inscription au panel IPSOS (possibilité d'avoir des bons d'achats)

  2. #22
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2005
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 8
    Points : 10
    Points
    10
    Par défaut
    Citation Envoyé par SQLpro
    Voici :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    -- mauvais 
       INSERT INTO T_CLIENT
              VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    -- bon 
       INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM, CLI_ENSEIGNE) 
              VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    -- excellent (insertion implicite des NULL) 
       INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM) 
              VALUES (198, 'M.', 'DUCORNET', 'Archibald')
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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')

  3. #23
    Membre averti
    Inscrit en
    Mars 2004
    Messages
    425
    Détails du profil
    Informations forums :
    Inscription : Mars 2004
    Messages : 425
    Points : 358
    Points
    358
    Par défaut
    Si j'ai bien suivi les explications , c'excellent de faire ceci
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM,CLI_VILLE) 
              VALUES (198, 'M.', 'DUCORNET', 'Archibald', 'LYON')
    OS:Win 2000 Pro, WIN XP
    SGBD: MS Sql Server, Oracle
    Environnement: VS.NET 2002, JBuilder
    Web: www.ndestudents.com

  4. #24
    Membre régulier Avatar de dark_vidor
    Homme Profil pro
    Élève
    Inscrit en
    Janvier 2005
    Messages
    321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Élève

    Informations forums :
    Inscription : Janvier 2005
    Messages : 321
    Points : 118
    Points
    118
    Par défaut
    Citation Envoyé par SQLpro
    Voici :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    -- mauvais 
       INSERT INTO T_CLIENT
              VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    -- bon 
       INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM, CLI_ENSEIGNE) 
              VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    ...
    Es ce que une requete de ce type :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?

  5. #25
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #26
    ced
    ced est déconnecté
    Rédacteur/Modérateur

    Avatar de ced
    Homme Profil pro
    Gestion de bases de données techniques
    Inscrit en
    Avril 2002
    Messages
    6 006
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Loiret (Centre)

    Informations professionnelles :
    Activité : Gestion de bases de données techniques
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Avril 2002
    Messages : 6 006
    Points : 23 668
    Points
    23 668
    Par défaut
    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
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  7. #27
    Membre confirmé Avatar de Monstros Velu
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    619
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2003
    Messages : 619
    Points : 601
    Points
    601
    Par défaut
    Citation Envoyé par ced
    la règle 12 ... la règle 16
    Je me posais la même question

  8. #28
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #29
    Membre actif
    Inscrit en
    Avril 2006
    Messages
    702
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 702
    Points : 289
    Points
    289
    Par défaut taille des tables
    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

  10. #30
    Membre régulier
    Inscrit en
    Octobre 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Âge : 35

    Informations forums :
    Inscription : Octobre 2009
    Messages : 86
    Points : 79
    Points
    79
    Par défaut
    Bonjour ,
    Merci beaucoup rien a dire chapeau pour vous

  11. #31
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 144
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Voici :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    -- bon 
       INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM, CLI_ENSEIGNE) 
              VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    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 !
    On ne jouit bien que de ce qu’on partage.

  12. #32
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  13. #33
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    141
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 141
    Points : 92
    Points
    92
    Par défaut
    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

  14. #34
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  15. #35
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonjour,


    Citation Envoyé par CinePhil Voir le message
    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...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  16. #36
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Optimisation du temps d'exécution d'une requête
    Par LeNovice dans le forum DB2
    Réponses: 6
    Dernier message: 12/07/2007, 14h47
  2. Comment optimiser les temps de réponse d'une requête ?
    Par renaudjuif dans le forum Requêtes
    Réponses: 3
    Dernier message: 19/02/2007, 15h12
  3. [Votre avis] J'attends vos commentaires :)
    Par Commodore dans le forum Mon site
    Réponses: 4
    Dernier message: 14/08/2006, 17h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo