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. #1
    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 Optimisation de votre SGBDR et de vos requêtes...
    Bonjour,

    De la ré écriture des requêtes au paramétrage du serveur en passant sur
    l'infrastructure système et l'influence des jeux de caractères sur la
    rapidité d'exécution de vos requêtes, vous saurez tout ce qu'il faut
    faire pour booster les performances de votre application et de votre
    SGBDR favori !

    A lire :
    http://sqlpro.developpez.com/OptimSQL/SQL_optim.html

    Frédéric BROUARD, expert SQL / bases de données
    Livre 'SQL' la référence - Campus Press éditeur
    * http://sqlpro.developpez.com/bookSQL.html *
    site web 'SQLpro' http://sqlpro.developpez.com/
    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/ * * * * *

  2. #2
    Expert éminent
    Avatar de neo.51
    Profil pro
    Inscrit en
    Avril 2002
    Messages
    2 663
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations forums :
    Inscription : Avril 2002
    Messages : 2 663
    Points : 6 418
    Points
    6 418
    Par défaut


    encore un exellent article qui va étayer ton site qui est déjà la référence pour le SQL

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 43
    Points : 30
    Points
    30
    Par défaut
    Vraiment vraiment super,

    C'est tout a fait ce qu'il me faut, je vais suivre les conseils au maximum, car ma BDD risque d'etre assez grande.

    une seule remarque:
    est ce que ceci est vraiment important



    deja que ma BDD est enorme je risque de l'emcombrer encore plus !


    Mais En tout ca chapeau , c vraiment du bon boulot.

  4. #4
    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
    Cela parait idiot en effet de faire une table de référence pour un sexe qui peut être représenté par un booléen.

    Mais comment savoir à quel sexe appartient TRUE ???

    Le seul moyen est quelque part d'avoir l'information de correspondance.

    Autrement dit une table de référence indiauant que TRUE = FEMME et FALSE = HOMME par exemple.

    C'est peut être trivial, mais si tu donne ta base de données à quelqu'un qui ne connait pas cette correspondance, quel moyen a t-il pour recoller l'information ???

    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/ * * * * *

  5. #5
    Membre actif
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Mars 2002
    Messages
    192
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Mars 2002
    Messages : 192
    Points : 252
    Points
    252
    Par défaut
    Souvent les informations sur le sexe ne sont pas booléènne ms ternaire :
    Homme, Femme, Indéterminé. Mais de là à créer une table pr ce genre d'informations...

    McFoggy
    Quelques tips Java & autres : mon blog

  6. #6
    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 en ne normalisant pas que tu risque de l'encombrer énormément.

    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

    As ton avis, quelle sera la requête la plus rapide... Celle sur la table 1 ou la table 2 ???

    Autrement dit la seconde solution possédant 11 fois moins de données ira 11 fois plus vite.
    Même si tu rajoute les temps d'accès aux tables de références (correctement indexées) le gain de temps sera considérable !!!

    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/ * * * * *

  7. #7
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2003
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2003
    Messages : 16
    Points : 16
    Points
    16
    Par défaut
    Pourquoi mettre SEX_ID comme INTEGER ???
    une definition du genre :

    SEXE char check value in ('M','F',null)
    (syntaxe a verifie mais vous comprendrez)

    cette definition est largement suffisante car:
    1-Il ne risque pas d'y avoir de nouveau sexe
    2-1 octet, donc encore moins gourmand en place qu'un integer
    3-permet l'indetermination avec la "valeur" null

  8. #8
    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
    1-Il ne risque pas d'y avoir de nouveau sexe
    2-1 octet, donc encore moins gourmand en place qu'un integer
    3-permet l'indetermination avec la "valeur" null
    Quelques éléments pour te répondre :

    1
    - C'est vrai !

    2
    - Moins gourmand en place de stockage mais plus que tu ne le croit : CHAR = 2 octets en ASCI et 4 en unicode. De plus nécessite l'appel d'une collation pour l'ordre des caractères. Enfin les processeurs sont taillés pour traiter des nombres et non des caractères. Ces deux éléments font qu'un litéral même moins grand qu'un entier est entre 2 et 4 fois moins rapide dans les traitements.

    3
    - NULL signifie que la donnée n'a pas été renseignée... Mais si je veut dire :
    SEXE inconnu (la personne ne l'a pas dit et il est pas évident d'affirmer qu'il s'agit d'un homme ou d'une femme)
    SEXE non déterminé (malformation de naissance ?)
    SEXE non applicable (escargot par exemple ?)
    SEXE impossible (personne morale - société, association par exemple ?)

    Comment vais je pouvoir rajouter ces différentes déclinaisons de mon information ?
    En autorisant mon utilisateur à modifier la structure de la table ??? (ALTER de la contrainte que tu as mis en outre en ligne plutôt qu'en contrainte de table ???)

    Non, le plus sage et le plus performant c'est le référencement.

    La seule exception concerne les informations immuables externe à l'univers que je modélise. Exemple les noms des jours, les noms des mois sont des informations universelles (en dehors du supporte de la langue) et sont dans un ensemble fermé de cardinalité fixe.

    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. #9
    Membre régulier
    Inscrit en
    Novembre 2002
    Messages
    67
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 67
    Points : 79
    Points
    79
    Par défaut
    SQL Pro tu peux m'expliquer ce truc stp :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    -- mauvais INSERT INTO T_CLIENT VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    -- bon INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM, CLI_ENSEIGNE) VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    -- excellent (insertion implicite des NULL) INSERT INTO T_CLIENT VALUES (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM) VALUES (198, 'M.', 'DUCORNET', 'Archibald')
    C la partie excelente que je comprends pas, merci.
    Java, JDBC, SQL, Oracle

    Specialiste Kamehameha des blagues-boulets

    Barman de la taverne

  10. #10
    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
    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 +
    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/ * * * * *

  11. #11
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    Bonjour,

    je m'étonne de la préco concernant l'espace disque à préserver (30% de l'espace totale)... Ca me parait extrémement couteux et j'arrive pas à trouver de justification à ce choix.

    Dans le cas d'Oracle par exemple, les tablespaces ont une taille définit par le DBA et on peut donc s'assurer le controle parfait de l'espace disque (les archives logs et traces diverses étant bien entendu sur des disques séparés).

    Alors si je conçois qu'on se laisse une réserve de 10-15% au cas où il faille agrandir des tablespaces, j'arrive pas à voir pourquoi le disque est plus lent lorsqu'il est rempli à 50 qu'à 80%. Les indexes permettent de retrouver l'adresse exact de l'info sur les disques donc le remplissage n'a que peut d'importance à ceci près qu la tête de lecture à plus de risque de parcourir de "longues" distance si les infos sont sur les extérieurs du cylindre entre autre

    Merci de préciser le fond de ta pensée pour éclairer ma lanterne

  12. #12
    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
    En fait c'est une constante des OS et des ressources disque.
    On s'aperçoit que les temps d'accès sont très constants tant que le disque est rempli à un taux N généralement situé vers 50 à 60%. Dès que le disque commence a dépasser ce stade, les temps d'accès augmentent de façon exponentiel.
    N'oublie pas que les fichiers sont fragmentés, à moins d'avoir demandé un fichier de taille fixe pour ta base, à la création du disque.
    Or moins il y a de la place plus la fragmentation est forte et distante.
    Je me souviens avoir vu fonctionner une base Paradox sur un disque ou il ne restait plus que quelque milliers d'octets : 2 heures pour une requête de quelques lignes qui mettait ordinairement moins d'une seconde. Mais l'OS y est quand même arrivé !

    on peut représenter le graphique de cette façon :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
     
    temps d'accès
        ^
        |
        |
        |
        |
        |
        |                                     _
        |
        |
        | 
        |                                   _ 
        |   
        |                                 __
        |                             ____
        |                       ______
        |_______________________
        |
        | 
         ----------------------------------------> Remplissage %
        0      20      40      60      80      100
    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/ * * * * *

  13. #13
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    Effectivement, je n'avais pas pensé aux problémes de fragmentation des fichiers

    Merci bien pour ces précisions

  14. #14
    Expert confirmé
    Avatar de Katyucha
    Femme Profil pro
    DevUxSecScrumOps Full Stack Bullshit
    Inscrit en
    Mars 2004
    Messages
    3 287
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Irlande

    Informations professionnelles :
    Activité : DevUxSecScrumOps Full Stack Bullshit

    Informations forums :
    Inscription : Mars 2004
    Messages : 3 287
    Points : 5 075
    Points
    5 075
    Par défaut
    Citation Envoyé par P'tit Jean
    SQL Pro tu peux m'expliquer ce truc stp :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    -- mauvais INSERT INTO T_CLIENT VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    -- bon INSERT INTO T_CLIENT (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM, CLI_ENSEIGNE) VALUES (198, 'M.', 'DUCORNET', 'Archibald', NULL)
    -- excellent (insertion implicite des NULL) INSERT INTO T_CLIENT VALUES (CLI_ID, TIT_CODE, CLI_NOM, CLI_PRENOM) VALUES (198, 'M.', 'DUCORNET', 'Archibald')
    C la partie excelente que je comprends pas, merci.
    En plus, si jamais, tu dois rajouter une colonne dans la table, tu dois modifier chaque insert existant dans ton code!
    Grave urgent !!!

  15. #15
    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
    Moins le SGBDR a de travail à faire, mieux cela vaut, donc sans précision de la liste des colonnes cible, il faut bien qu'il aille les retrouver dans le dictionnaire des données. D'ou une requête supplémentaire.

    Si vous préciser une liste de colonnes et que pour certaines la valeur est NULL puisque vous ne voulez pas la renseigner, alors vous passez au serveur une requête dont la longeur du texte est supérieur à une requête équivamente dans laquelle on ne mentionnerait que les colonnes utiles.
    Certes cela porte sur quelques caractères...
    Mais quand une table possède 10 millions de lignes, alors quelques caractères multiplié par 10 millions, cela fait beaucoup de méga octets inutile véhiculé sur le réseau.

    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/ * * * * *

  16. #16
    Inscrit
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 319
    Points : 476
    Points
    476
    Par défaut
    Qu'en est-il de la facon de faire comme suit :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    INSERT INTO `table` SET
    colonne  = 'valeur',
    colonne2 = 'valeur2'
    Cela revient-il exactement au même que la version 'excellent' de dessus ?

  17. #17
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    cette syntaxe n'est pas correcte

    mais sinon ce serait tout aussi bon, l'idée étant de ne pas laisser au SGBD le soin de rechercher les colonnes mais de lui indiquer... ceci étant, c'est rarement ça qui dégrade les performances

  18. #18
    Inscrit
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    319
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 319
    Points : 476
    Points
    476
    Par défaut
    bweu, bien sur que si elle est correcte, sous MySQL4 en tout cas

    edit : tout dépend de ce que tu appelle correct en fait

  19. #19
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Citation Envoyé par winzou
    bweu, bien sur que si elle est correcte, sous MySQL4 en tout cas

    edit : tout dépend de ce que tu appelle correct en fait
    Etonnant car normalement on fait un
    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
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    UPDATE matable SET col=..., col2=...
    mais je connaissais pas le
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO matable SET ...

  20. #20
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 073
    Points
    19 073
    Par défaut
    effectivement barbi c'est ce que je voulais dire

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