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

Affichage des résultats du sondage: Combien votre base de données contient-elle de tables avec plus de 20 colonnes ? (une seul choix pos

Votants
40. Vous ne pouvez pas participer à ce sondage.
  • Moins de 5%

    24 60,00%
  • Moins de 10%

    4 10,00%
  • Moins de 20%

    5 12,50%
  • PLUS de 20%

    7 17,50%
Optimisations SGBD Discussion :

Petites tables ou grandes tables. . . Quelles conséquences sur les performances ?


Sujet :

Optimisations SGBD

  1. #21
    Membre expérimenté Avatar de Yanika_bzh
    Homme Profil pro
    Responsable Applicatif et R&D
    Inscrit en
    Février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : Février 2006
    Messages : 1 144
    Points : 1 738
    Points
    1 738
    Par défaut
    Citation Envoyé par iberserk Voir le message
    J'allais le dire....

    SQL PRO: le couple affiché sur la fiche technique est le couple développé par le moteur... il ne dépend donc pas de la boite de vitesse.

    Mais nous chipotons...
    Peut etre est il en train de comprendre l'art de la mécanique !
    Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)

  2. #22
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    1 040
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 1 040
    Points : 1 041
    Points
    1 041
    Par défaut
    Bonjour,
    pour l'exemple cité précédemment pour les caractéristiques il est possible de faire une table Moteur une autre des types de caractéristiques et une troisième liant le moteur, 2 le type de caractéristique et 3 la valeur mesurée. Dans ce cas au lieu d'une table on en a 3 et très peu de colonnes comme le préconise SQL PRO.
    L'avantage est que si vous rajoutez une nouvelle caractéristique vous n'avez pas à modifier la table mais seulement la rajouter dans la table des types de caractéristiques, les trois tables sont liées par des clés Auto numériques .
    Peut être que c'est une mauvaise méthode étant autodidacte cela fonctionne tout de même.
    Cordialement

  3. #23
    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
    Je vais me faire l'avocat du diable, et plussoyer dans la direction de Yanika_bzh :

    Pour un événement (commande, facture, etc.) :

    société d'appartenance
    achat ou vente
    type d'événement
    code état
    référence externe
    code catégorie
    numéro de contrat associé
    devise
    type du tiers livré
    sigle du tiers livré
    numéro d'adresse de livraison
    type du tiers facturé
    sigle du tiers facturé
    numéro d'adresse de facturé
    type du tiers commercial
    sigle du tiers commercial
    numéro d'adresse de commercial
    numéro d'événement
    type du tiers associé
    sigle du tiers associé
    date de saisie
    utilisateur ayant saisi
    date de validation
    utilisateur ayant validé
    date de modification
    utilisateur ayant modifié
    date de livraison
    date d'expédition
    date de facturation
    société d'appartenance de l'évènement d'origine
    achat/vente de l'évènement d'origine
    type de l'évènement d'origine
    numéro de l'évènement d'origine
    nombre d'éditions
    mode de livraison
    mode de transport
    sigle du transporteur
    sigle du vendeur
    code analitique
    mode de règlement
    délais de règlement
    quantième du règmement
    dépôt serveur
    position fiscale
    code tva



    Voilà, 45 champs. Et encore, j'ai pas tout mis, on peut en trouver d'autres si on entre dans le détail ou dans le spécifique.

    Pour les tiers :

    société d'appartenance
    type de tiers
    sigle du tiers
    nom du tiers
    code comptable du tiers
    nom banque
    code banque
    code guichet
    numéro de compte
    clé rib
    mode de règlement
    délais de règlement
    quantième de règlement
    encours maximum
    période de facturation
    nombre de copies factures
    position fiscale
    code incident
    date de modification
    utilisateur ayant fait la modification
    type de facture
    famille
    code barème
    devise
    vendeur
    groupe
    langue
    transpoteur
    mode de livraison
    mode de transport
    délais de réappro
    statut
    date de gréation

    Allez, 33 colonnes.

    Encore une fois, je n'ai pas mis ce qui pouvait être spécifique.

    Cherchez-moi la dénormalisation là dedans, je suis curieux de trouver quelquechose qui ne soit pas en 1-1 et qui soit potentiellement NULL.
    On ne jouit bien que de ce qu’on partage.

  4. #24
    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
    Sinon, j'ai arrêté la lecture de l'article au moment de l'exemple sur les téléphones. Il est on ne peut plus mauvais :

    1/ Un numéro de téléphone a une taille potentiellement variable (si j'ai des clients à l'internationnal, tous les numéros n'ont pas la même longueur).
    => J'utilise donc un VARCHAR. Un NULL ne perdra que deux bytes.

    2/ Dans ma table téléphonique, vu que potentiellement j'ai beaucoup de tiers, je vais utiliser une clé assez grande (int32 par exemple). Voir pire, la même clé que celle de mon tiers, qui est peut-être un VARCHAR lui aussi.
    => Je suis donc dans le cas cocasse où ma seconde table prend systématiquement plus de place dans la base que si j'avais laissé mes numéros de téléphone dans la table principale.

    3/ Si dans un écran je veux afficher les informations de mon tiers ainsi que les trois numéros de téléphone, je dois faire 2 requêtes de suite, et une boucle pour parcourir mon second résultat afin de mettre le bon numéro en face du bon masque de saisie. Avec ma table "fourre tout", une seule requête aurait suffit, et aucun traitement particulier au moment de l'affichage.

    4/ Idem pour les mises à jour. Sans oublier que je vais devoir gérer les cas UPDATE/INSERT pour chaque numéro saisi, avec potentiellement une démultiplication de SELECT ou gestion d'erreures inutiles.

    5/ La table des numéros de téléphone va faire en moyenne 2 fois plus de ligne que la table des clients. Si stocker 1,5 champ vide par ligne pose un problème de performances sur la table client, je ne suis pas sûr que rajouter une table deux fois plus grosse vienne changer quoi que ce soit au niveau des performances : les index c'est bien, mais si y'a trop de ligne, ça ramme quand même...

    Si sur le fond, cet article prèche un convaincu, sur la forme il est à corriger :

    Moins d'extrêmisme :
    - La dénormalisation n'est pas toujours plus lourde en termes de taille des données.
    - La dénormalisation évite souvent des traitements post-requête (ou pré-requête) qui peuvent être lourd.

    De meilleurs exemples :
    - La franchement, le coup du des numéros de téléphones, c'est naze. Prends plutôt l'exemple des informations client saisie dans la commande.

    Un meilleure objectivité :
    - On ne dénormalise pas toujours parcequ'on ne sais pas ce qu'est une base de données : on s'est souvent posé la question de l'intérêt de la dénormalisation ou non.
    On ne jouit bien que de ce qu’on partage.

  5. #25
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Dans ma table téléphonique, vu que potentiellement j'ai beaucoup de tiers, je vais utiliser une clé assez grande (int32 par exemple)
    int32 est sur 4 octets, aucun rapport avec la taille d'un numéro de téléphone?

    Si stocker 1,5 champ vide par ligne pose un problème de performances sur la table client, je ne suis pas sûr que rajouter une table deux fois plus grosse vienne changer quoi que ce soit au niveau des performances : les index c'est bien, mais si y'a trop de ligne, ça ramme quand même...
    Vous ne posez qu'un index sur votre table des téléphone!
    Je serais curieux de voir la tête de vos index recouvrant les téléphones sur votre table client "fourre tout"

    Que faites vous le jour ou vous voulez un troisième, 4ème numéro de téléphone?

    Quant à votre exemple de table avec 45 colonnes... no comment :
    société d'appartenance de l'évènement d'origine
    achat/vente de l'évènement d'origine
    type de l'évènement d'origine
    numéro de l'évènement d'origine
    Ça ce n'est pas externalisable?
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  6. #26
    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 iberserk Voir le message
    int32 est sur 4 octets, aucun rapport avec la taille d'un numéro de téléphone?
    Ben si justement.
    Un VARCHAR avec la valeur NULL dedans, c'est 2 octets.
    Là, on va avoir systématiquement 4 octets consommés en plus par numéro de téléphone rempli.
    Le gain de place est donc potentiellement négatif.

    Dans la base sur laquelle je travaille, j'ai comme clé de mes tiers une clé composite formée d'un NUMBER(38), VARCHAR2(3) et d'un VARCHAR2(12).
    Grmpf, la clé est déjà plus grosse qu'un numéro de téléphone !

    Citation Envoyé par iberserk Voir le message
    Vous ne posez qu'un index sur votre table des téléphone!
    Je serais curieux de voir la tête de vos index recouvrant les téléphones sur votre table client "fourre tout"
    Personnellement, quand je vois la tronche des données dans l'exemple, je ne vais pas indexer mes téléphones hein... J'aimerais savoir comment tu peux faire une recherche par numéro sans imposer un masque de saisie !
    Quant à l'avantage d'avoir un seul index plutôt que plusieurs index sur une même table euh... comment dire... A moins d'utiliser Access comme SGBD ensuite ou DBase, je ne vois pas l'intérêt. Au contraire, plusieurs index sur une même table garantissent de meilleurs performances lorsqu'on utilise l'index dédié à ce qu'on recherche...

    Citation Envoyé par iberserk Voir le message
    Que faites vous le jour ou vous voulez un troisième, 4ème numéro de téléphone?
    Ca, je suis parfaitement d'accord. Au détail près qu'on n'est pas en train de discuter des avantages d'une bonne modélisation, mais du gain en performances apporté par une légère dénormalisation.
    Deplus, il y a des tas de moyens très simples à mettre en place pour augmenter le nombre de colonnes d'une table sans modifier le modèle des données.

    Citation Envoyé par iberserk Voir le message
    Quant à votre exemple de table avec 45 colonnes... no comment :

    Ça ce n'est pas externalisable?
    Ben trouve une seule colonne externalisable, et t'auras droit à un choco...
    On ne jouit bien que de ce qu’on partage.

  7. #27
    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
    Pour un événement (commande, facture, etc.) :

    société d'appartenance => Clé étrangère
    achat ou vente
    type d'événement => Clé étrangère
    code état => Clé étrangère
    référence externe => Clé étrangère
    code catégorie => Clé étrangère
    numéro de contrat associé => Clé étrangère et pas le numéro de contrat mais son identifiant
    devise => Clé étrangère
    type du tiers livré }
    sigle du tiers livré } => Non pas type et sigle clé étrangère référençant l'identifiant du tiers livré donc une seule colonne au lieu de deux !
    numéro d'adresse de livraison => Clé étrangère
    type du tiers facturé }
    sigle du tiers facturé } => Idem ci-dessus
    numéro d'adresse de facturé => Clé étrangère, et il n'y a généralement qu'une seule adresse de facturation pour un tiers donc supprimable car dépendant du tiers facturé.
    type du tiers commercial }
    sigle du tiers commercial } => Idem ci-dessus
    numéro d'adresse de commercial => dépend du commercial donc à supprimer
    numéro d'événement
    type du tiers associé }
    sigle du tiers associé } => Idem ci-dessus
    date de saisie
    utilisateur ayant saisi => Clé étrangère
    date de validation
    utilisateur ayant validé => Clé étrangère
    date de modification
    utilisateur ayant modifié => Clé étrangère
    date de livraison
    date d'expédition
    date de facturation
    société d'appartenance de l'évènement d'origine => Clé étrangère
    achat/vente de l'évènement d'origine => Clé étrangère
    type de l'évènement d'origine => Dépend de l'événement d'origine donc à supprimer
    numéro de l'évènement d'origine => Clé étrangère
    nombre d'éditions
    mode de livraison => Clé étrangère
    mode de transport => Clé étrangère
    sigle du transporteur => Non pas sigle mais clé étrangère référençant l'identifiant du transporteur
    sigle du vendeur => Non pas sigle mais clé étrangère référençant l'identifiant du vendeur
    code analitique => Clé étrangère
    mode de règlement => Clé étrangère
    délais de règlement
    quantième du règlement
    dépôt serveur => Quesaquo ?
    position fiscale => Clé étrangère
    code tva => Clé étrangère



    Voilà, 45 champs. Et encore, j'ai pas tout mis, on peut en trouver d'autres si on entre dans le détail ou dans le spécifique.
    Grande majorité de clés étrangères donc informations externalisées. En plus, on peut fortement douter de la pertinence de cette table car plutôt qu'un événement fourre-tout pour "commande, facture, etc.", il vaut mieux faire des tables séparées pour les commandes, les factures, les livraisons... et même pour les lignes de chaque commande, facture ou livraison !

    Bref, mauvais exemple !

    Ben trouve une seule colonne externalisable, et t'auras droit à un choco...
    Avec tout ce que j'ai trouvé, tu peux donner le paquet je crois ! Miam !

    Dans la base sur laquelle je travaille, j'ai comme clé de mes tiers une clé composite formée d'un NUMBER(38), VARCHAR2(3) et d'un VARCHAR2(12).
    Beurk ! Pas de VARCHAR dans les clés ! Contre-performant ! En plus, je ne connais pas Oracle, mais si j'interprète correctement ce que je lis dans la doc, NUMBER(38) peut occuper beaucoup plus d'octets qu'un entier donc pas à choisir comme type pour une clé non plus.

    Personnellement, quand je vois la tronche des données dans l'exemple, je ne vais pas indexer mes téléphones hein... J'aimerais savoir comment tu peux faire une recherche par numéro sans imposer un masque de saisie !
    Il est très rare qu'on ait besoin de chercher une information à partir d'un numéro de téléphone dont on ne connaît pas le détenteur donc on ne posera pas d'index sur le numéro de téléphone mais bien évidemment il y aura un index sur l'identifiant du numéro de téléphone, lequel sera un entier auto-incrémenté. Admettons que ce soit un entier long si tu as l'intention de mémoriser plus de 2 milliards de numéros de téléphones !
    Quant au détenteur, comme il peut y en avoir plusieurs pour un numéro de téléphone (un numéro de service pour plusieurs personnes dans le service), on peut même faire une table associative entre la table des téléphones et la table des personnes, cette dernière étant une généralisation des personnes morales et des personnes physiques.

    Au détail près qu'on n'est pas en train de discuter des avantages d'une bonne modélisation
    C'est pourtant un préalable indispensable avant de pré-supposer qu'une dénormalisation puisse être utile.
    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 !

  8. #28
    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
    Pour l'ensemble des informations que tu as flagué comme "clé étrangères" : ben oui, c'est bien des clés étrangères. Mais ça n'empêche pas que ça reste une colonne dans ma table...

    code société + type tiers + sigle tiers : ce sont des clés étrangères, et ma table des tiers a justement une clé composite.
    => dis-moi à quoi ça sert d'avoir un numéro auto-incrément ? à part avoir un index pourri ? de toute façon, en interne, la clé est déjà représentée comme un rowid, et les jointures portent sur cette valeur. donc aucun intérêt à rajouter des informations inutiles.

    pour l'adresse de facturation, ça se voit que tu travailles pas dans la grande distribution. il peut y avoir des adresses différentes par PDL, et même par nature de produits.

    "numéro d'adresse de commercial". il y a une faute de frappe dedans. il s'agit de l'adresse commerciale. c'est à dire l'adresse d'où provient la commande, l'adresse de l'interlocuteur qui a passé la commande.

    un évènement a ici pour clé composite son code société, achat/vente, type et numéro.
    => a nouveau, à quoi sert une clé dénuée de sens, là où une clé composite offrira les même performances en utilisant des champs ayant du sens ?

    sigle transporteur et vendeur : comme pour les autres tiers, il s'agit bien d'une partie de son identifiant (code société et type de tiers étant déductibles de l'évènement, via une table de paramétrage)

    dépôt serveur : sigle du tiers dépôt (avec la même règle que les autres tiers), à partir duquel doit partir la machandise. ça sert principalement pour faire des contrôles au niveau de l'assortiment produit, qu'on ne demande pas au préparateur de mettre des produit inexistants dans le dépôt sur le quai de chargement... sinon y'en a qui vont pas être contents.

    => donc non, t'as pas trouvé un seul élément externalisable.

    => non, une table commune pour tous les type d'événement est vitale, ces informations sont identiques qu'on soit en devis, commande, livraison, facture, avoir ou retour, transfert inter-dépôt, transfert inter-société, démarques, etc..
    Et grace à sa clé composite, elle est aussi performante que si on avait créé une table par société et type d'événement... au détail près que les mêmes requêtes (et binaires, procédure stockées, vues, triggers, etc.) peuvent servir pour des types d'événement différents.

    les clés en varchar sont aussi performantes que les clé en int (renseigne-toi un peu, on n'est plus en 1970, c'est d'index qui est lu physiquement, et donc le rowid)


    Si t'es pas convaincu par la modélisation et par les performances, lit la requête suivante, le résultat, et explique-moi comment tu feras mieux que 3 secondes pour obtenir le résutlat avec une table par société/type d'évènement :
    Sans oublier comment tu feras le jour où t'as un nouveau type d'événement à prendre en charge ? Et une nouvelle société ?
    Si tu utilises une table commune, t'as l'air malin avec ta clé numérique.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    select ut_soc.libut_soc societe, tev.lib1 typevt, count(*) nbevt
    from ut_soc /* société */
    inner join eve /* Evénements */ on eve.codsoc = ut_soc.soc
    inner join tbl tev /* Type d'événement */ on tev.codsoc = eve.codsoc and tev.codtbl = 'tev' and tev.cletbl = eve.typeve
    where eve.achvte = 'V' /* flux de vente */
    group by ut_soc.libut_soc, tev.lib1
    ;
    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
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    SOCIETE		TYPEVT				NBEVT
    --------------- ------------------------------- -------
    Société 1       Facture                            8134
    Société 1       Commande                           7072
    Société 1       Livraison                          7079
    Société 1       Avoir prix                          121
    Société 1       Avoir qté avec stock                246
    Société 1       Avoir qté sans stock                256
    Société 1       Facture pro-forma client             11
    Société 1       Avoir qté avec stock Société 2      173
    Société 2       Devis                                41
    Société 2       Retour                             2253
    Société 2       Facture	                        1219293
    Société 2       Commande                        1291741
    Société 2       Livraison                       1336524
    Société 2       Transfert                        158235
    Société 2       Avoir prix                        59685
    Société 2       Avoir qté avec stock              68491
    Société 2       Avoir qté sans stock              79220
    Société 2       Facture prix hors régul             558
    Société 2       Facture pro-forma client          26334
    Société 2       Avoir qté avec stock Société 2     8500
    Société 3       Facture                            5152
    Société 3       Commande                           5170
    Société 3       Livraison                          5171
    Société 3       Avoir prix                           99
    Société 3       Facture prix hors régul              29
    Société 3       Facture pro-forma client              2
    Société 3       Avoir qté avec stock Société 2       33
    Société 4       Facture                          109292
    Société 4       Commande                         101080
    Société 4       Livraison                        101429
    Société 4       Dossier litige                     6389
    Société 4       Facture pro-forma client            406
    Société 5	Offre                                10
    Société 5	Facture                               7
    Société 5	Commande                             17
    Société 5	Livraison                            22
    Société 5	Commande directe                     13
    Société 5	Devis Grand Export                    1
    Société 5	Avoir qté avec stock Société 2        3
    On ne jouit bien que de ce qu’on partage.

  9. #29
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    les clés en varchar sont aussi performantes que les clé en int (renseigne-toi un peu, on n'est plus en 1970, c'est d'index qui est lu physiquement, et donc le rowid)
    aie

    Personnellement, quand je vois la tronche des données dans l'exemple, je ne vais pas indexer mes téléphones hein... J'aimerais savoir comment tu peux faire une recherche par numéro sans imposer un masque de saisie !
    Quant à l'avantage d'avoir un seul index plutôt que plusieurs index sur une même table euh... comment dire... A moins d'utiliser Access comme SGBD ensuite ou DBase, je ne vois pas l'intérêt. Au contraire, plusieurs index sur une même table garantissent de meilleurs performances lorsqu'on utilise l'index dédié à ce qu'on recherche...
    Vous me rappelez mon ancien directeur technique... a qui j'ai du refaire une partie de la base de données en Aout dernier car sa 'modélisation a toute épreuve' faisait qu'un hopital entier était bloqué...

    Sérieusement si vous voulez qu'on réponde calmement à vos "réponses" évitez d'être systématiquement agressif surtout quand vous prônez de la part du rédacteur un ton moins affirmatif...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  10. #30
    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 iberserk Voir le message
    aie
    Au lieu de dire "aïe", montre-moi comment tu vas faire pour faire la requête ci-dessus de façon optimisée ?

    En interrogeant 50 tables avec 50 union ?
    En ajoutant un index... sur la clé composite (utilité de la clé dans ce cas ?)

    Bref, moi j'attends.


    Moi j'ai toujours entendu dire qu'une bonne modélisation commençait par ne pas ajouter de l'information inutile. Mettre un ID numérique dans notre cas, c'est rajouter de la donnée pour rien. A aucun moment il sera judicieux de l'utiliser plutôt que la clé composite.
    On ne jouit bien que de ce qu’on partage.

  11. #31
    Membre éprouvé Avatar de Oishiiii
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2009
    Messages
    508
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Août 2009
    Messages : 508
    Points : 1 104
    Points
    1 104
    Par défaut
    C'est pas inintéressant en tout cas.

  12. #32
    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 iberserk Voir le message
    aie

    Vous me rappelez mon ancien directeur technique... a qui j'ai du refaire une partie de la base de données en Aout dernier car sa 'modélisation a toute épreuve' faisait qu'un hopital entier était bloqué...

    Sérieusement si vous voulez qu'on réponde calmement à vos "réponses" évitez d'être systématiquement agressif surtout quand vous prônez de la part du rédacteur un ton moins affirmatif...
    Excuse-moi, je m'emporte facilement, il est vrai, désolé.

    Mais avoue que depuis que Yanika_bzh a osé mettre en doute la bonne parole de l'article, y'a pas un argument qui tienne réellement la route dans les réponses.
    Quelques tentatives, certes, mais pas un seul qui soit retenable.

    Ensuite, quand je lis qu'il ne faut pas mutualiser les tables, et ne pas utiliser de clés composites, excuse-moi, mais ici on parle de SGBD, Oracle, SQL Server, PostgreSQL, pas de DBase IV ou d'Access.

    J'ai jamais vu un seul cas où une clé composite pouvait provoquer la moindre contre-performance. Au contraire. Dans mon exemple, elle me permet d'utiliser l'index unique de la PK d'une unique table pour récuéprer un ensemble conséquent de lignes. On peut pas faire plus optimisé.
    On ne jouit bien que de ce qu’on partage.

  13. #33
    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
    [quote=StringBuilder;6222986]
    => dis-moi à quoi ça sert d'avoir un numéro auto-incrément ? à part avoir un index pourri ?
    Un peu de lecture t'en apprendra plus sur la grande utilité des clés auto-incrémentées.
    Pourquoi cela donnerait-il un index pourri ? Au contraire, cela donne les meilleurs index quand ces clés primaires auto-incrémentées sont référencées comme clés étrangères dans les autres tables !

    de toute façon, en interne, la clé est déjà représentée comme un rowid, et les jointures portent sur cette valeur. donc aucun intérêt à rajouter des informations inutiles.
    Sauf que le ROWID est en fait une chaîne de caractères donc un index moins performant pour une clé étrangère.

    pour l'adresse de facturation, ça se voit que tu travailles pas dans la grande distribution. il peut y avoir des adresses différentes par PDL, et même par nature de produits.
    OK admettons.

    "numéro d'adresse de commercial". il y a une faute de frappe dedans. il s'agit de l'adresse commerciale. c'est à dire l'adresse d'où provient la commande, l'adresse de l'interlocuteur qui a passé la commande.
    Et l'adresse d'où provient la commande ne dépend pas d'une autre information dans ta table ?

    un évènement a ici pour clé composite son code société, achat/vente, type et numéro.
    => a nouveau, à quoi sert une clé dénuée de sens, là où une clé composite offrira les même performances en utilisant des champs ayant du sens ?
    As-tu fait des tests pour affirmer ça ? Avec des clés alphanumériques, ça m'étonnerait beaucoup que ce soit mieux qu'avec des entiers !

    sigle transporteur et vendeur : comme pour les autres tiers, il s'agit bien d'une partie de son identifiant (code société et type de tiers étant déductibles de l'évènement, via une table de paramétrage)
    J'ai l'impression que c'est inutilement compliqué ton machin !

    dépôt serveur : sigle du tiers dépôt (avec la même règle que les autres tiers), à partir duquel doit partir la machandise. ça sert principalement pour faire des contrôles au niveau de l'assortiment produit, qu'on ne demande pas au préparateur de mettre des produit inexistants dans le dépôt sur le quai de chargement... sinon y'en a qui vont pas être contents.
    Encore un type alphanumérique !

    => non, une table commune pour tous les type d'événement est vitale, ces informations sont identiques qu'on soit en devis, commande, livraison, facture, avoir ou retour, transfert inter-dépôt, transfert inter-société, démarques, etc..
    Dès le devis, tu sais quel produit partira de tel endroit pour arriver à tel autre et sera facturé à tel endroit ... ? Bref, toutes les colonnes sont elles NOT NULL pour tous les événements ?
    Parce que si en plus tu pollues ta table avec le bonhomme NULL !

    Et grace à sa clé composite, elle est aussi performante que si on avait créé une table par société et type d'événement...
    Qui te parle de créer une table par société ?

    les clés en varchar sont aussi performantes que les clé en int (renseigne-toi un peu, on n'est plus en 1970, c'est d'index qui est lu physiquement, et donc le rowid)
    C'est contraire à ce que j'ai lu jusqu'à présent sur Developpez.com ! Tout simplement parce que les VARCHAR sont le plus souvent plus gros que les entiers (à partir de VARCHAR(4)).
    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 !

  14. #34
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Je dis aîe pour la citation que je fais juste au dessus pas pour votre requête.

    Le problème ici n'est pas la performance mais l’intérêt d'une telle table?

    La table est du coups énorme, l'ajout/modification d'une commande (exemple) met à jour tous vos indexes, y compris pour les autres 'types' qui n'ont rien à voir, problème que vous n'auriez pas en éclatant cette table.

    Vous nous parlez de performances en lecture... quel est le but de la requête? une REPORT? Vous avez des bases OLAP pour ça pourrais je vous répondre...

    Quid des performances en ajout?en modification voir suppression?
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  15. #35
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    C'est contraire à ce que j'ai lu jusqu'à présent sur Developpez.com ! Tout simplement parce que les VARCHAR sont le plus souvent plus gros que les entiers (à partir de VARCHAR(4)).
    Sans compter des effort supplémentaires lié à la COLLATION?
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  16. #36
    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 iberserk Voir le message
    La table est du coups énorme, l'ajout/modification d'une commande (exemple) met à jour tous vos indexes, y compris pour les autres 'types' qui n'ont rien à voir, problème que vous n'auriez pas en éclatant cette table.
    Pas si les index (et heureusement c'est le cas) prennent toujours les trois premiers champs de la clé composite (codsoc, achvte, typeve) : ainsi, si j'ajoute une commande de vente, même si j'ai un index par exemple sur la date, je ne mettrai à jour l'index que pour la partie qui concerne les commande de vente de ma société en cours.

    Donc non, le coût sera le même.

    Citation Envoyé par iberserk Voir le message
    Vous nous parlez de performances en lecture... quel est le but de la requête? une REPORT? Vous avez des bases OLAP pour ça pourrais je vous répondre...

    Quid des performances en ajout?en modification voir suppression?
    Il s'agissait ici d'un exemple bidon effectivement, mais qui permettait de souligner un peu l'intérêt des clés composites.

    Un autre exemple plus parlant, c'est de faire le suivit événément :
    Lorsque je suis sur une facture, je souhaite connaître par quelles étapes elle est passée pour en arriver là.

    Je peux avoir un flux cde->liv->fac, devis->arbitrage->cde->préparation->liv->fac

    A ce moment, à nouveau, avec une table par type d'évènement, je vais pleurer quand je vais devoir faire l'écran qui permet à un utilisateur de savoir quelle commande à bien pu générer cette facture, alors qu'ici, une bête requête hiérarchique et c'est bon.

    Sinon, on peut penser aussi aux écrans de recherche : si je veux la liste de toutes les livraisons de ce jour, si on mutualise la table pour la raison expliquée ci-dessus, sans clé composite, c'est la croix et la banière niveau performances.
    On ne jouit bien que de ce qu’on partage.

  17. #37
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Sinon, on peut penser aussi aux écrans de recherche : si je veux la liste de toutes les livraisons de ce jour, si on mutualise la table pour la raison expliquée ci-dessus, sans clé composite, c'est la croix et la banière.
    Pourquoi? au contraire vous avez une simple table dédiée aux livraisons avec la date?

    Il s'agissait ici d'un exemple bidon effectivement
    Comme les téléphones? ok je vous charrie...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  18. #38
    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
    Ben non, parceque dans un écran de recherche, je peux tout à fait vouloir rechercher tous les événéments de mon client, pas seulement les livraisons.

    => Imagine si j'ai des types d'événements différents correspondant à un flux spécifique (livraison denrées périssables et livraison standard par exemple).

    Au moment de la facure, je veux pouvoir ajouter à la fois les livraisons de denrés périssables et les livraisons standard.

    Et là, je suis obligé de me lancer :
    - Dans du développement spécifique
    - De la requête spécifique
    - Des performances amenuisées à grands coups de union dans plusieurs tables

    Alors qu'avec mon exemple, j'ai juste à chercher tous les élément de vente de ma société dont le type fait partie d'une liste (et dont le tiers est mon client).
    Ce sera donc le même écran de recherche selon les besoins et les types d'événement, et surtout, la même requête.
    On y gagne donc à tous les niveaux, y compris en performances.
    On ne jouit bien que de ce qu’on partage.

  19. #39
    Membre expérimenté Avatar de Yanika_bzh
    Homme Profil pro
    Responsable Applicatif et R&D
    Inscrit en
    Février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : Février 2006
    Messages : 1 144
    Points : 1 738
    Points
    1 738
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    que depuis que Yanika_bzh a osé mettre en doute la bonne parole de l'article.
    On parle de moi ??
    Je n'ai pas mis en doute la bonne parole de l'article, juste répondu a un intervenant qui jurait qu'une table comporant plus de 20 colonnes ne pouvait exister. J'ai posté un contre exemple, et voila...

    Concernant votre exemple, il n'est pas du meme type que celui dont je parlais. Dans mon cas, cela concernait les propriétés atomiques. Dans le votre c'est plus lié a une modélisation et une gestion des relations. J'aurai meme fait une entitée "INTERVENANT", liée a vos differents tiers, leur role d'intervention et l'objet sur lequel il intervient (commande, facture, ...).
    Cela aurait eu pour conséquence de supprimer vos références tiers dans votre table... Mais ce n'est pas le lieu pour debattre sur un modele issu d'un exemple.

    Concernant l'utilisation de clés primaires ALPHA, j'ai eu affaire a de nombreux projets en contenant. Je n'ai pas remarqué performances immondes et detestables (et pourtant, domaine industriel, pilotage d'automates donc proche du T.R.). Pour les clés il faut surtout se focaliser sur la notion d'immuabilité, plutot que sur les performances présumées (de plus, lors que nous avions réalisé un moteur SGBD en C++ comme projet d'etudes, nous utilisions une table de HASH pour la comparaison stricte, donc ormis le pouilleme de temps de calcul du HASH, et la comparaison de quelques bits supplémentaires, je ne suis pas sur que les gains soient si enormes que cela. La génération d'un auto incrément demande elle aussi un travail processeur, ainsi qu'une gestion stricte de la concurrence), et en ce domaine, l'utilisation d'un clé entiere incrementale est la plus sure (= clé technique qui vous assure que quelque soit les evolutions dans le temps des elements liées a cette clé, les relations perdureront)
    Bref, pour moi et en gros, la normalisation est un gain dans la qualité du code qui risque d'etre généré, un gain aussi dans l'evolutivité et la maintenance post développement. Il n'en reste que certains projets ancestraux, n'appliquant pas ces principes et ne demandant pas d'évolutions, continuent encore a tourner avec des performances redoutables !

    Bien a vous
    Dans la connaissance du monde, ceux qui ne savent rien en savent toujours autant que ceux qui n'en savent pas plus qu'eux. (Pierre Dac)

  20. #40
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 811
    Points
    17 811
    Par défaut
    Honnêtement StringBuilder, sortir un exemple concret que seul vous pouvez analyser et utiliser n'a pas énormément d'intérêt, tout simplement parce qu'il est impossible de vous challenger que ce soit sur votre base ou votre applicatif.

    Les différents intervenants ont montré que votre modélisation n'est pas parfaite, néanmoins pas parfait n'est pas synonyme de complètement inutilisable et comme Yanika_bzh le concluait précédemment il reste de nombreuses applications très robustes qui ne sont pas normalisées.

    N'oubliez pas de prendre en compte que SQLPro est très soucieux de la différenciation des modèles physiques (tables) et externes (vue).
    Je m'avance certainement, mais votre grosse table repartie sur une dizaine de tables et regroupée dans une (ou plusieurs) vue(s) vous donnerait à minima plus de souplesse et probablement plus de performances.

    Vos problématiques de recherches seraient aussi bien gérées par une vue, les jointures sur des clefs coûtent très peu dès lors que vous avez filtré une table fille sur un certain nombre de critères.

    Sur le coups des index, s'ils accélèrent les sélections ils ralentissent fortement les mises à jour et suppressions, cherchez dans le forum vous trouverez des exemples de batch qui passent de plusieurs heures à quelques minutes juste par la suppression des index.

    Enfin sur la performance d'un index en fonction de son type (littéral ou numérique), chez Oracle c'est similaire, chez SQL-Server c'est très différent, il n'y a pas de bonne réponse universelle.

Discussions similaires

  1. Impact sur les performances avec un grand nombre de tables
    Par enila dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 04/08/2011, 16h40
  2. Une grande table VS 2 tables de taille correcte
    Par mikaeru dans le forum Optimisations
    Réponses: 3
    Dernier message: 11/06/2011, 17h17
  3. [AC-2003] séparer une grande table en sous table par année
    Par MatAir dans le forum Requêtes et SQL.
    Réponses: 1
    Dernier message: 25/03/2011, 20h24
  4. Réponses: 3
    Dernier message: 04/01/2011, 16h05
  5. Impact sur les performances d'un grand nombre de tables
    Par thechief dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 16/07/2010, 17h47

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