Discussion :

[pekre]

Bonjour,
je voudrai savoir si des colonnes(codlabel0 à codlabel9) d'une table contiennent des valeur que j'ai ('13','17','20','21','24','24','27','29','31','32')
j'ai fait une requete qui marche bien, je voudrai l'ameliorer car je pense qu'il y'a mieux que ce que j'ai fait.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
select  norg,codlabel0,codlabel1,codlabel2,codlabel3,codlabel4,codlabel5,codlabel6,codlabel7,codlabel8,codlabel9 from org   
    		   where   codlabel0 in('13','17','20','21','24','24','27','29','31','32') or codlabel2 in('13','17','20','21','24','24','27','29','31','32') or 
    		   codlabel3 in('13','17','20','21','24','24','27','29','31','32') or  codlabel4 in('13','17','20','21','24','24','27','29','31','32')
    		   or  codlabel5 in('13','17','20','21','24','24','27','29','31','32') or  codlabel6 in('13','17','20','21','24','24','27','29','31','32')
    		   or  codlabel7 in('13','17','20','21','24','24','27','29','31','32') or  codlabel8 in('13','17','20','21','24','24','27','29','31','32')
    		   or  codlabel9 in('13','17','20','21','24','24','27','29','31','32')

merci de votre aide

[SQLpro]

C'est votre modèle qui est à chier !
On ne fait pas un pseudo tableaux dans une table avec des colonnes ...1, ..2, ... , ...9 c'est d'une stupidité sans nom, qui viole par apocope la première forme normale et vous obligera à des requêtes tordues, ineptes et contre performante !

Modélisez correctement en ayant une table avec deux colonnes : indice et codelabel

A +

[mathieu_BO]

@SQLPro
Revoir le modèle, pourquoi pas ?
1 table element (el_id, name)
1 tables config (id, el_id, prop_num, value)
Ensuite element.el_id = config.prop_num et la value on y met les fameux nombres qui peuvent renvoyer à une autre table de propriété... ou rien.
D'ailleurs il semble qu'il faille mettre des INT partout ici et non du charactere !
C'est bien çà que vous préconiser SQLPro ?

Mais pourquoi revoir le modèle ?
Imaginons, que cette table de configuration soit une configuration type liste de propriétés qui sont TOUJOURS TOUTES renseignées (colonnes définies non nulles).
Alors le bonus de performance d'espace disparait car de toute façon soit elle est complète soit elle est pas là contrairement au modèle avec une table à deux colonnes effectivement.
En terme de rapidité, simplicité de requêtage ...effectivement je me pose la question, des index etc.

pour le IN ('13','17','20','21','24','24','27','29','31','32') c'est à proscrire : mettre ces valeurs dans une table temporaire avec jointure ou un NOT EXISTS.

>> La çà tient bon non ? Qu'en pensez vous ?
(J'ai bien envie de me faire contre carré par un expert SGBDR )

PS: je reviens sur l'objectif initial : "chercher une valeur parmi une liste" : donc oui 1 table à 2 colonnes + un index béton sur la VALUE mais faut voir si c'est une demande spontanée versus le projet global je pense.

Après... on peut indexer chaque colonnes et faire une requête séparé de recherche qui utilisera chacune chaque index... ?

[escartefigue]

Le modèle à plat qui est le votre, nécessite 10 index pour les colonnes de données + l'index PK de l'indentifiant, soit 11 index dont un seul unique
Ca veut dire que chaque insertion concerne 11 index (voir plus si d'autres colonnes sont indexées, par exemple les FK)
C'est énorme, ca ralentit considérablement les requêtes de mise à jour (insert, update, delete)

Et, comme vous le constatez par vous même, interroger sur un critère simple comme une liste de valeurs est un exercice difficile.

Si l'on suit votre raisonnement et que les colonnes concernent les données journalières sur une année, allez vous mettre 366 colonne dans la table, et donc 366+1 index

Cerise sur le gateau : si vous devez mettre à jour une seule des valeurs parmi les 10, avec un modèle à plat comme le votre, pendant la mise à jour de cette valeur même avec un verrou minimal c'est à dire de taille "row", vous bloquez toute mise à jour des autres valeurs par d'autres threads, là où une modélisation respectueuse des formes normales ne pose aucun souci. Soit une deuxième source de ralentissement en plus du boulet au pied lié au nombre d'index pléthoriques.

Le respect des formes normales n'est pas une coquetterie, c'est un incontournable

[SQLpro]

@SQLPro
Revoir le modèle, pourquoi pas ?
1 table element (el_id, name)
1 tables config (id, el_id, prop_num, value)
Ensuite element.el_id = config.prop_num et la value on y met les fameux nombres qui peuvent renvoyer à une autre table de propriété... ou rien.
D'ailleurs il semble qu'il faille mettre des INT partout ici et non du charactere !
C'est bien çà que vous préconiser SQLPro ?

Mais pourquoi revoir le modèle ?
Imaginons, que cette table de configuration soit une configuration type liste de propriétés qui sont TOUJOURS TOUTES renseignées (colonnes définies non nulles).
Alors le bonus de performance d'espace disparait car de toute façon soit elle est complète soit elle est pas là contrairement au modèle avec une table à deux colonnes effectivement.
En terme de rapidité, simplicité de requêtage ...effectivement je me pose la question, des index etc.

C'est la bonne question a se poser. Plus votre table à de colonne, plus le nombre d'index sera démentiel et vous n'arriverez jamais à l'optimiser correctement. Pour info, pour une table de 10 colonnes, il faudrait théoriquement poser plusieurs millions d'index pour l'optimiser dans tous les cas de recherche. En effet le nombre d'index est la somme des arrangement des index en prenant 1 puis, 2, puis 3, ... colonnes !

Tout ceci est parfaitement décrit dans mon livre sur SQL, y compris la formule mathématique pour calculer le nombre potentiel d'index relationnel (B Tree) simple, en fonction du nombre de colonnes de la table.



A +

[mathieu_BO]

Bonjour @escartefigue
Moi je viens de la BI donc les modèles on en a à plétore (coûts dev/perfs/design/maintenance/machines) on est très flexible contrairement à l'opérationnel qui lui a bien son jolie modèle 3NF à respecter etc.

exemple simple :
1 transaction est rattachée à un produit et un produit à une catégorie.
je peux modéliser :
Transaction -> Produit -> Categorie
ou Catégorie <- Transaction -> Produit pour raison de performance car je fais + souvent mon rapport sur la catégorie sans le produit

on a les contraintes de reporting et les demandes d'évolution business
ex : mon produit change de catégorie, quel modèle je préfère ?
Catégorie CatHist <- Transaction -> CatActu
ou Catégorie CatHist <- Transaction -> Produit -> CatActu

Donc en amont il y'a bien un modèle histo_produit_catégorie ou non (alors on essaye de traquer le changement) mais le lien se met à jour donc nous aussi.
On veut que ça s'applique à toutes les transactions avec perte de l'info historique ?
Solution 1) Update des transaction (c'est moche on fait çà le week end)
Solution 2) on a le lien via le produit donc 2 objets manipulables (histo/actuel)
On veut de la performance car beaucoup de rapports tournent que sur la categorie actuelle, ben on le met en dur aussi directement dans la transaction.

Donc si je cite @SQLPro

C'est votre modèle qui est à chier !

Non, le modèle s'adapte en fonction du besoin (voir les datamarts modèles étoiles/flocons en fonction du besoin business vs contrainte technique)
Si je vous cite @escartefigue

Le respect des formes normales n'est pas une coquetterie, c'est un incontournable

C'est contournable en BI

Allez j'essaye un exemple que je modélise sous Business Objects :
1 element a 1 liste de Transactions
1 transactions a ses 9 colonnes : trans_id, el_id, date_creation, date_mise_jour, date_prévu_lancement, date_reelle, date_debut, date_limite, date_fin, date_cloture_par_le_client
>> moi je go direct 3 tables avec pleins de liens (alias) depuis la transaction vers une table date

si je veux nom de l'element, debut et fin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select e.name, debut.date as date_debut, fin.date as date_fin
from element e
inner join transaction t on t.el_id = e.el_id
inner join date as debut on debut.date_id = t.date_debut_id
inner join date as fin on fin.date_id = t.date_fin_id

Si je prend le modèle de @SQLPro c'est l'enfer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
select e.name, debut.date as date_debut, fin.date as date_fin
from element e
inner join transaction t on t.el_id = e.el_id
inner join date_list dld on dl.trans_id = t._trans_id and dld.type = 'debut'
inner join date debut on dld.date_id = debut.date_id
inner join date_list dlf on dlf.trans_id = t._trans_id and dlf.type = 'fin'
inner join date fin on dl.date_id = fin.date_id

>> Trop de jointures, l'horreur en général SAUF pour la demande précise de @Pekre (une seule jointure, on se fout du type de date)

et encore là c'est retournement de situation comme vous me l'avez fait avec les jours et années car faut que je m'assure qu'il n'y ait qu'une date de debut ou fin(check unicity trans_id,type). alors que le modèle en colonne le valide par lui même.
En fait ici ce modèle à plusieurs colonnes est justifié même dans un modèle relationnel.

@SQLpro, je viens de voir votre réponse, coté Index, je suis pas callé, j'ai travaillé avec des experts sur MSSQLServer qui se sont cassé la tête effectivement, analyse et refonte des indexes, où mettre les INCLUDE, les vues matérialisées etc, au final on a plus d'espace d'index que de données. On fait des opérations le week end, on met en place des infra physique type loadbalancing. Pour avoir l'écriture sur un serveur et le reporting sur un autre.
Après y'a la méthode de désactivation et .... on attend qu'un utilisateur se plaigne

[SQLpro]

C'est stupide de votre part de ne pas nous avoir mentionné que votre base est pour de l'OLAP (BI) sans cette précision, nous sommes tous partit sur du relationnel !

Donc on a bossé pour vous en vain !

Merci

Pour information, tournez vous vers les index ColumStore... C'est ce qu'il y a de plus adapté pour le BI sur de grosses volumétries (plusieurs centaines de millions de lignes)

A +

[escartefigue]

Je plussoie, il y a d'ailleurs une section consacrée pour éviter les confusions

Par défaut, la réponse est orientée relationnel

[mathieu_BO]

Euh Mr/MmePerke n'a pas mentionné le terme BI, c'est moi qui ai répondu à sa demande par une requête avec mon background BI, sorry for that
Je resterais focus relationnel dans cette section la prochaine fois, je savais pas que la section BI existait merci