Publicité
+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 36 sur 36
  1. #21
    Membre chevronné Avatar de pinocchio
    Homme Profil pro François
    Développeur informatique
    Inscrit en
    novembre 2002
    Messages
    796
    Détails du profil
    Informations personnelles :
    Nom : Homme François
    Âge : 37
    Localisation : France, Yvelines (Île de France)

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

    Informations forums :
    Inscription : novembre 2002
    Messages : 796
    Points : 779
    Points
    779

    Par défaut

    Citation 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.

  2. #22
    Invité de passage
    Inscrit en
    février 2005
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 8
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par SQLpro
    Voici :
    Code :
    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 :
    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 :
    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 :
    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')

  3. #23
    Membre éclairé
    Inscrit en
    mars 2004
    Messages
    425
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 425
    Points : 300
    Points
    300

    Par défaut

    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')
    OS:Win 2000 Pro, WIN XP
    SGBD: MS Sql Server, Oracle
    Environnement: VS.NET 2002, JBuilder
    Web: www.ndestudents.com

  4. #24
    Membre du Club
    Inscrit en
    janvier 2005
    Messages
    245
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 245
    Points : 54
    Points
    54

    Par défaut

    Citation Envoyé par SQLpro
    Voici :
    Code :
    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 :
    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 :
    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 294
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 294
    Points : 27 313
    Points
    27 313

    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 :
    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
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

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

    Avatar de ced
    Homme Profil pro Cédric Duprez
    Gestion de bases de données techniques
    Inscrit en
    avril 2002
    Messages
    5 041
    Détails du profil
    Informations personnelles :
    Nom : Homme Cédric Duprez
    Âge : 39
    Localisation : France, Loiret (Centre)

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

    Informations forums :
    Inscription : avril 2002
    Messages : 5 041
    Points : 16 533
    Points
    16 533

    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

  7. #27
    Membre éprouvé Avatar de Monstros Velu
    Homme Profil pro Vincent
    Développeur informatique
    Inscrit en
    janvier 2003
    Messages
    571
    Détails du profil
    Informations personnelles :
    Nom : Homme Vincent
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2003
    Messages : 571
    Points : 475
    Points
    475

    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 Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 294
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 294
    Points : 27 313
    Points
    27 313

    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
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  9. #29
    Membre confirmé
    Profil pro Luis
    Inscrit en
    avril 2006
    Messages
    677
    Détails du profil
    Informations personnelles :
    Nom : Luis

    Informations forums :
    Inscription : avril 2006
    Messages : 677
    Points : 219
    Points
    219

    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
    Nouveau Membre du Club
    Profil pro Amine djouk
    Inscrit en
    octobre 2009
    Messages
    86
    Détails du profil
    Informations personnelles :
    Nom : Amine djouk
    Âge : 26

    Informations forums :
    Inscription : octobre 2009
    Messages : 86
    Points : 37
    Points
    37

    Par défaut

    Bonjour ,
    Merci beaucoup rien a dire chapeau pour vous

  11. #31
    Membre Expert Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 671
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : février 2010
    Messages : 1 671
    Points : 2 217
    Points
    2 217

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Voici :
    Code :
    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 !

  12. #32
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 747
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    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 : 13 747
    Points : 22 930
    Points
    22 930

    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 de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « 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 du Club
    Inscrit en
    mars 2007
    Messages
    134
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 134
    Points : 54
    Points
    54

    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 Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 747
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    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 : 13 747
    Points : 22 930
    Points
    22 930

    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 de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « 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 Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 633
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

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

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 633
    Points : 12 289
    Points
    12 289

    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...
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  16. #36
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 294
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 294
    Points : 27 313
    Points
    27 313

    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
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •