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

Développement SQL Server Discussion :

Génération des valeurs


Sujet :

Développement SQL Server

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Gestionnaire de parc micro-informatique
    Inscrit en
    Mai 2014
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Algérie

    Informations professionnelles :
    Activité : Gestionnaire de parc micro-informatique

    Informations forums :
    Inscription : Mai 2014
    Messages : 52
    Points : 9
    Points
    9
    Par défaut Génération des valeurs
    bonjour,
    j'ai deux table conçu en sql server :
    table client (id_cl,nom,adresse,....)
    et la table article (num_art,libelle_art)
    la relation entre les deux tables c'est la table
    avoir_article (id_cl,num_art) de type (1,N - 1,N)
    ce que je veux savoir est comment pour chaque jour faire une génération des quantités de chaque articles pour chaque client
    client 1 va avoir ces quantités d'article 1, article 2 qui correspondant

  2. #2
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    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 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    J'ai pas très bien compris la question...

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    insert into avoir_article (id_cl, id_ar)
    select c.id_cl, a.id_ar
    from client c
    cross join article a

    Je doute que ce soit ce que tu cherches, mais c'est ce que j'ai compris

    Ou si tu veux connaître la quantité de chaque article pour chaque client ?

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    select id_cl, id_ar, count(*)
    from avoir_article
    group by id_cl, id_ar

    ?????
    On ne jouit bien que de ce qu’on partage.

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    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 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par fatnews Voir le message
    bonjour,
    j'ai deux table conçu en sql server :
    table client (id_cl,nom,adresse,....)
    et la table article (num_art,libelle_art)
    la relation entre les deux tables c'est la table
    avoir_article (id_cl,num_art) de type (1,N - 1,N)
    Votre modélisation est mauvaise... Il serait plus intelligent de faire un MCD plutôt que de se jeter sur la création des tables.
    Dans ce cas vous auriez vu que pour compléter votre modèle il faut rajouter la quantité de produits vendu.

    Au final vos tables devraient être conçues avec les éléments suivants :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    CREATE table client 
    (id_cl      INT PRIMARY KEY, 
     nom, adresse,....);
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    CREATE table article 
    (num_art    INT PRIMARY KEY,
     libelle_art, ...);
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    CREATE table avoir_article
    (id_cl      INT NOT NULL FOREIGN KEY REFERENCES client (id_cl),
     num_art    INT NOT NULL FOREIGN KEY REFERENCES article (num_art),
     quantite   FLOAT NOT NULL DEFAULT 1,
    PRIMARY KEY (id_cl, num_art));
    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/ * * * * *

  4. #4
    Futur Membre du Club
    Homme Profil pro
    Gestionnaire de parc micro-informatique
    Inscrit en
    Mai 2014
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Algérie

    Informations professionnelles :
    Activité : Gestionnaire de parc micro-informatique

    Informations forums :
    Inscription : Mai 2014
    Messages : 52
    Points : 9
    Points
    9
    Par défaut
    bonjour à tous, et merci pour votre collaboration, je vais essayer d'expliquer un peux plus claire.
    bien sur j'ai un MCD et il est valider et mes tables son conçu bien en sql server comme tu a écrit
    la table relationnelle avoir_article son clé primaire est la concaténation de (id_client,num_art) des deux tables qui relie
    c'est-à-dire chaque client a le minimum 1 et le maximum N de produit et pour l'article est livrer pour 1 ou N client
    dans mon exemple ici j'ai trois articles
    donc chaque client a une quantité (x) d'article 1
    et une quantité (y) d'article 2
    et une quantité (z) d'article 3

    ces quantités sons générer de la table avoir_article
    pour faire cette requête sincèrement je suis bloqué

  5. #5
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    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 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par fatnews Voir le message
    la table relationnelle avoir_article son clé primaire est la concaténation de (id_client,num_art) des deux tables qui relie
    Erreur de conception.
    Si dans un MPD, l'identifiant d'une entité est composé, lors du passage au SQL, sous SQL Server tout particulièrement, la clé primaire doit SYSTEMATIQUEMENT être un numérique entier auto-incrémenté (tinyint, smallint, int, bigint) pour des raisons de performance.
    C'est cette clé qui sera organisée en cluster.
    Et la "clé" qui est mise en évidence dans le MPD est alors transcrite sous forme de CONTRAINTE D'UNICITE (c'est à dire une clé alternative).
    Sans ça, vous allez vous heurter à des problèmes de performance non seulement à la lecture dans la table, mais aussi, et surtout, lors de l'insertion de données dans la table, car SQL Server va passer son temps à décaller les données déjà écrite à cause de l'index organisé en cluster sur des données qui ne sont pas ordonnées en fonction de leur âge.

    Citation Envoyé par fatnews Voir le message
    ces quantités sons générer de la table avoir_article
    pour faire cette requête sincèrement je suis bloqué
    Cette partie ne veut ABSOLUMENT rien dire. Comme dans la question originale.

    "Générer", c'est créer physiquement (INSERT) des données à partir d'un algorithme.
    Je doute fortement que vous vouliez générer quoi que ce soit ici, mais plutôt calculer (pour un stockage ? pour une édition ?).
    Et à partir de quoi ?

    Quelles quantités ?

    Je reste sur mes deux requêtes initiales, testez-les, et regardez si elles vous conviennent. (gros doute pour la première ceci dit).

    Sinon, expliquez ce que vous voulez calculer, et à partir de quoi.

    Vous nous parlez de la table avoir, sans nous dire sa structure ni ce qu'elle contient.
    On ne jouit bien que de ce qu’on partage.

  6. #6
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Bonjour,
    Citation Envoyé par StringBuilder Voir le message
    Erreur de conception.
    Si dans un MPD, l'identifiant d'une entité est composé, lors du passage au SQL, sous SQL Server tout particulièrement, la clé primaire doit SYSTEMATIQUEMENT être un numérique entier auto-incrémenté (tinyint, smallint, int, bigint) pour des raisons de performance.
    C'est cette clé qui sera organisée en cluster.
    Je n'y vois pas une erreur de conception.
    utiliser le couple formé par les deux clefs étrangères comme clef primaire d'une table associative est tout à fait correct.
    Au niveau de l'index, il convient en effet de spécifier un taux de remplissage adéquat en fonction de l'utilisation de table (insertion, mises à jour,...), et de veiller à sa maintenance.



    Citation Envoyé par StringBuilder Voir le message
    Et la "clé" qui est mise en évidence dans le MPD est alors transcrite sous forme de CONTRAINTE D'UNICITE (c'est à dire une clé alternative).
    Sans ça, vous allez vous heurter à des problèmes de performance non seulement à la lecture dans la table, mais aussi, et surtout, lors de l'insertion de données dans la table, car SQL Server va passer son temps à décaller les données déjà écrite à cause de l'index organisé en cluster sur des données qui ne sont pas ordonnées en fonction de leur âge.
    En créant votre contrainte d'intégrité (certes nécessaire dans ce cas), vous créerez fatalement l'index que vous pointez du doigt...
    Vous vous retrouvez donc avec la problématique initiale (maintenance de l'index formé par les deux clefs étrangères) mais avec un index cluster en plus à maintenir (lequel sera en plus dans doute inutilisé en lecture dans la pluspart des cas).
    On est donc perdant sur toute la ligne

  7. #7
    Futur Membre du Club
    Homme Profil pro
    Gestionnaire de parc micro-informatique
    Inscrit en
    Mai 2014
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Algérie

    Informations professionnelles :
    Activité : Gestionnaire de parc micro-informatique

    Informations forums :
    Inscription : Mai 2014
    Messages : 52
    Points : 9
    Points
    9
    Par défaut
    je suis un peu perdu voici mon MLD
    Client: Code_cl, Nom-cl, Adresse, Ord-cl, Num_RC, Num_com#, Num_wil#, Num_lg#
    Article: Num_Art, Libelle_Art,prix
    QUOTAS : Code_cl,Num_Art,Qtt_du_jour

    ma question est comment généré les qtt_du_jour pour chaque client quotidiennement (chaque jour) ni calcule ni rien (les quantités indiquer dans la table Quotas
    sont des quantités fixes )

  8. #8
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    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 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message
    Je n'y vois pas une erreur de conception.
    Conception, non, effectivement, mais une erreur d'implémentation.

    Citation Envoyé par aieeeuuuuu Voir le message
    utiliser le couple formé par les deux clefs étrangères comme clef primaire d'une table associative est tout à fait correct.
    Correct d'un point de vue purement "conception merise".
    Au niveau SQL Server, il y a un énorme impact au niveau des performances de ce dernier, qui gère très mal les clés composées (c'est à mon sens une énormité de la part d'un SGBD professionnel, mais c'est comme ça).

    Citation Envoyé par aieeeuuuuu Voir le message
    Au niveau de l'index, il convient en effet de spécifier un taux de remplissage adéquat en fonction de l'utilisation de table (insertion, mises à jour,...), et de veiller à sa maintenance.
    Le taux de remplissage n'y fera rien.
    Les produits et les clients ne vieillissent pas de façon harmonieuse (le best seller peut rester un des plus anciens produits, tout comme le meilleur client peut être un client historique). Par conséquent, l'index sera forcément complètement déséquilibré.
    Mais c'est pas vraiment l'index qui me tient en souci, mais l'organisation en cluster des données. La saisie de nouveaux produits sur un client historique (ou la saisie de clients sur un produit historique, ça dépend de l'ordre des colonnes) va fatalement produire des déplacement de blocs de données volumineux à un moment où à un autre. Et un taux de remplissage faible, pour s'en prémunir, va de facto produire des trous béants dans le fichier de données, pour la majorité des produits et clients qui n'ont pour ainsi dire aucun mouvement (nouveaux, anciens qui ne sont plus utilisés, etc.) Les trous aussi sont source de problèmes de performances.

    Citation Envoyé par aieeeuuuuu Voir le message
    En créant votre contrainte d'intégrité (certes nécessaire dans ce cas), vous créerez fatalement l'index que vous pointez du doigt...
    Non, car il ne' sera pasz organisé en cluster. Donc OSEF qu'il soit déséquilibré à cause des volumes différents d'un produit/client à l'autre : avant tout les données seront réparties de façon homogènes dans la base, et les données regroupées par âge, ce qui correspond le mieux, généralement, aux besoins en termes de lecture/écritures dans les tables.

    Citation Envoyé par aieeeuuuuu Voir le message
    Vous vous retrouvez donc avec la problématique initiale (maintenance de l'index formé par les deux clefs étrangères) mais avec un index cluster en plus à maintenir (lequel sera en plus dans doute inutilisé en lecture dans la pluspart des cas).
    On est donc perdant sur toute la ligne
    Ben non, l'index cluster par défaut, sur l'entier auto-incrémenté n'aura pour ainsi dire pas besoin de maintenance (logiquement) car du moment qu'on passe pas son temps à supprimer des lignes, il n'y aura aucun trou.
    On ne jouit bien que de ce qu’on partage.

  9. #9
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    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 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par fatnews Voir le message
    je suis un peu perdu voici mon MLD
    Client: Code_cl, Nom-cl, Adresse, Ord-cl, Num_RC, Num_com#, Num_wil#, Num_lg#
    Article: Num_Art, Libelle_Art,prix
    QUOTAS : Code_cl,Num_Art,Qtt_du_jour

    ma question est comment généré les qtt_du_jour pour chaque client quotidiennement (chaque jour) ni calcule ni rien (les quantités indiquer dans la table Quotas
    sont des quantités fixes )
    Dans la table quota, il manque une date, pour regrouper par jour.

    Ensuite, ma seconde requête (cf. premier poste) est suffisante, il suffit de rajouter la date comme critère de regroupement (dans le SELECT et dans une clause GROUP BY)
    On ne jouit bien que de ce qu’on partage.

  10. #10
    Futur Membre du Club
    Homme Profil pro
    Gestionnaire de parc micro-informatique
    Inscrit en
    Mai 2014
    Messages
    52
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Algérie

    Informations professionnelles :
    Activité : Gestionnaire de parc micro-informatique

    Informations forums :
    Inscription : Mai 2014
    Messages : 52
    Points : 9
    Points
    9
    Par défaut
    j'ai utiliser la requête qui combine entre insert et select
    mais on peut pas la reexécuter une deuxième fois il accepte pas la clé en double
    mon bute c'est d’exécuter la procédure chaque jour avec les même client et les même quantités

  11. #11
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    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 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Erreur de conception.
    NON
    Si dans un MPD, l'identifiant d'une entité est composé, lors du passage au SQL, sous SQL Server tout particulièrement, la clé primaire doit SYSTEMATIQUEMENT être un numérique entier auto-incrémenté (tinyint, smallint, int, bigint) pour des raisons de performance.
    NON !!!

    Une clef PRIMAIRE CLUSTERED composée de 2 colonnes, ne me choque pas et il n'y a qucune obligation, ni systématisation à avoir, même pour des raisons de perf.

    En effet, si les deux tables sont en lien n::m et que chacun a une clef primaire INT autoincrémentée, alors la table de jointure aura une clef composée des deux clefs, soit 2 INt de 32 bits => clef de 64 bits, lue en une seule passe dans le processeur (64 bits).

    De plus si la table de jointure est organisée de façon à avoir en premier la clef la plus fréquemment jointe/groupée et en second la moins, alors c'est plus gagnant qu'avec une seule clef, qui va entremêlée les lignes de différentes commandes au lieu de les grouper !

    Démo :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    table de jointure AVOIR1 avec clef primaire COM_ID et PRD_ID
    table de jointure AVOIR2 avec clef primaire AVR_ID autoinc + UNIQUE(COM_ID et PRD_ID)
    Insérons des lignes :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    COM_ID       PRD_ID
    ------------ -------------
    11           999
    11           555
    12           888
    11           777
    11           444
    13           666
    11           222
    Voici le résultat dans la table AVOIR1 (clustered)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    COM_ID       PRD_ID
    ------------ -------------
    11           222
    11           555
    11           444
    11           777   
    11           999
    12           888
    13           666
    Voici le résultat dans la table AVOIR2 (clustered)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    AVR_ID       COM_ID       PRD_ID
    ------------ ------------ -------------
    1            11           999
    2            11           555
    3            12           888
    4            11           777
    5            11           444
    6            13           666
    7            11           222 
    Comme on le voit dans l'index CLUSTERED AVOIR 1 les lignes sont groupées par commande ce qui n'est pas le cas de AVOIR2. La mise en cache sera donc meilleure pour AVOIR1

    CQFD !


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

  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 736
    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 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Au niveau SQL Server, il y a un énorme impact au niveau des performances de ce dernier, qui gère très mal les clés composées (c'est à mon sens une énormité de la part d'un SGBD professionnel, mais c'est comme ça).
    ben non, voir démo ci après !

    Avez vous des tests pour affirmer cela de façon aussi péremptoire ?.

    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
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    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 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Hmmm, à moins que ça n'ait changé depuis quelques années, je me suis fait pourrir sur ce même forum pour avoir utilisé des clés composée.

    J'ai donc argumenté, fort de cette expérience.

    Quant aux exemple que vous donnez, je dirais qu'ils sont biaisés.

    En effet, vous avez comme membre de la clé "avoir_id" par exemple. C'est une donnée donc la valeur évolue de façon linéraire dans le temps.

    L'avoir 1 sera lu en 2014, et n'aura aucune chance d'être lu en 2020.

    En revanche, notre ami a des données qui sont bien moins linéaires dans le temps.

    Le stylo bic existe depuis 1945 et est sans aucun doute, reste LE best-seller dans toutes les papeteries du monde.

    Et l'entreprise "petites affiches" existe depuis 1612, et est sans conteste l'un des clients les plus réguliers pour certaines papeteries.

    BREF. Donc dans le cas de notre amis, le produit 1 et le client 1, relégués tout en tête du fichier de données, ont autant de mises à jour (voir plus) que le dernier produit marketing Marvell à la mode et la société de services qui vient de s'ouvrir juste à côté, donc les données sont elles, tout à la fin du fichier de données, à plusieurs Go de distance des autres.

    Et au milieu, il y a des millions de couples composés de client et produits morts (le gamin de 12 ans qui en en 40 aujourd'hui et qui achetait des Panini des Schtroumpfs, qui n'existent plus aujourd'hui).

    Et là, Petite Affiche décide de réassortir ses fournitures, et demande à insérer 50000 lignes dans la table.
    => Plusieurs µGo de données à déplacer pour faire de place.

    Personnellement, cet argument me convainc.

    Je me trompe peut-être, mais voici un exemple (qui me semble correspondre à la problématique de notre ami) qui fait que je ne suis pas certain que la clé composée soit la meilleure chose.
    On ne jouit bien que de ce qu’on partage.

Discussions similaires

  1. Tri des valeurs dans un DBGrid
    Par soviet dans le forum C++Builder
    Réponses: 3
    Dernier message: 11/06/2015, 15h18
  2. Réponses: 10
    Dernier message: 01/02/2011, 10h02
  3. Décaler des valeurs dans un tableau
    Par sh2003 dans le forum Langage
    Réponses: 6
    Dernier message: 20/03/2004, 17h01
  4. [SQL] Ma requête m'oblige à saisir des valeurs manuellement
    Par bossun dans le forum Requêtes et SQL.
    Réponses: 4
    Dernier message: 22/10/2003, 14h29
  5. Réponses: 6
    Dernier message: 04/04/2003, 16h28

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