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

[Yanika_bzh]

Envoyé par iberserk

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 !

[cbleas]

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

[StringBuilder]

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.

[StringBuilder]

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.

[iberserk]

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?

[StringBuilder]

Envoyé par iberserk

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 !

Envoyé par iberserk

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

Envoyé par iberserk

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.

Envoyé par iberserk

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

[CinePhil]

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.

[StringBuilder]

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 :

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 :

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

[iberserk]

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

[StringBuilder]

Envoyé par iberserk

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.

[Oishiiii]

C'est pas inintéressant en tout cas.

[StringBuilder]

Envoyé par iberserk

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

[CinePhil]

[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)).

[iberserk]

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?

[iberserk]

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?

[StringBuilder]

Envoyé par iberserk

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.

Envoyé par iberserk

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.

[iberserk]

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

[StringBuilder]

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.

[Yanika_bzh]

Envoyé par StringBuilder

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

[Waldar]

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.